New options for timeZoneName to yield numeric representations

💡 Ideas
1

Hi, this is just a small proposal, so I'm not sure where the correct location is to post it. I'll try here.

The Intl.DateTimeFormat constructor defines a timeZoneName options field, which
lets the user define the way the timezone is formatted when serializing a date instance.
The 2 possible options are:

  • 'long' => Central European Summer Time
  • 'short' => GMT+2

Documentation on MDN

I'm now proposing two more options called numeric-short and numeric-long which would yield a ISO8601 compatible numeric offset:

  • 'numeric-short' => +02
  • 'numeric-long' => +02:00

What do you think?

2

Hi Adrian, and welcome :-)

at this stage, your message would have been better posted in the "ideas" forum. An admin will probably move it there.

The "numeric-short" format is fine as an input format, but for output you can't express fractional time zones. The "short" format actually expands to the four digits versions in that case.

Intl.DateTimeFormat("en-US", {
  timeZone: "Asia/Calcutta",
  timeZoneName: "short"
}).format(new Date)

// "2/28/2020, GMT+5:30"

For numeric-short this leaves us with at least three possibilities:

  • throw for fractional time zones
  • return a four digits version when needed. This means that client code will have to take variable output into account
  • drop it, and rename "numeric-long" just "numeric"...

I'd lean on the latter option. Fewer branches in client code. Fewer possible ways to misuse the API.