DateTimeFormat: consider adding more timezone display options

[jungshik]

Currently, there are only two values for timeZoneName option in Intl.DateTimeFormat; short and long. v8 implementation maps them to 'z' and 'zzzz'. (I don't know what Firefox does because the latest release still does not seem to support timezones other than UTC)

For America/New_York, 'z' in en-US would be EST or EDT (depending on whether DST is in effect or not) and 'zzzz' in 'Eastern Standard/Daylight Time'. In many other locales (including en-AU or en-NZ), 'z' would be '{GMT,UTC}-5' or '{GMT,UTC}-4' (because EST/EDT is North America/US-specific and is not unique).

However, CLDR has a few more ways to display timezones. For instance, ZZZZ (gmtOffset format) or VV (long timezone id) can be useful.

See http://cldr.unicode.org/translation/date-time and
http://unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names

[zbraniecki]

@anba - any thoughts on that?

for the record, Firefox has timezones support in 52, currently in Aurora channel.

[littledan]

@zbraniecki What do you mean by timezone support--long and short, as in the current spec, or more formats?

[zbraniecki]

IANA timezone names - https://bugzilla.mozilla.org/show_bug.cgi?id=837961

[jungshik]

for the record, Firefox has timezones support in 52, currently in Aurora channel.

Good to know. I only tried Firefox 50. It looks like I have to download the tarball for 52 directly from frirefox (Ubuntu PPA is still at 51.x : https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/firefox-aurora ).

[jungshik]

It appears that Firefox 52 also maps 'short' and 'long' to 'z' and 'zzzz'.

[jungshik]

http://unicode.org/reports/tr35/tr35-dates.html#dfst-zone has the full list of timezone formats in CLDR.
There are more than a dozen formats listed in the table.

Currently, only the first two (z and zzzz) are supported with 'short' and 'long'.

I found the following to be useful in addition to z and zzzz.

Z, ZZZZ : UTC offset ; -0800, GMT-0800
v, vvvv: short and long non-specific names: PT and Pacific Time (as opposed to PDT/PST and Pacific Daylight/Standard Time)
V, VV, VVV, VVVV: uslax, America/Los_Angeles, Los Angeles, Los Angeles Time

[caridy]

We should be open to such proposal, we just need a champion.

[littledan]

I can champion such a thing if needed, I'm just wondering if anyone can say more about motivating use cases.

I believe this came up when Jungshik was looking into implementing Date.prototype.toString in V8, to get the three/four-letter timezone name. However, as it turned out, CLDR was not an appropriate source of such a short name which would match what some platforms exposed previously (maybe it's good for other things though).

Do we want to expose all of these, or pick out the ones that make the most sense for users? Should we use CLDR's names, or pick our own names and a mapping?

[caridy]

Do we want to expose all of these, or pick out the ones that make the most sense for users? Should we use CLDR's names, or pick our own names and a mapping?

We should definitely pick up our own names since the skeleton is not exposed to users in any way, that train left the station a long time ago :)

[maggiepint]

Should we use CLDR's names, or pick our own names and a mapping?

Can you clarify that statement? Pick our own time zone names?

[littledan]

@maggiepint I mean, should ECMA 402 make up new names, in addition to "short", "long", we could have "iana", "medium", "itty-bitty", "ginormous", etc (I haven't looked closely enough into what proper names would be).

Generally, if we are designing a new translation into a new set of names that we're just making up, it makes me a little bit worried that we've made a design mistake. This just makes things that much more annoying for users--now they have to look through the mapping of new names to old names.

[rxaviers]

At PayPal, I haven't seen any use case requiring different time zone display names than what's already available. For example, 'July 21, 2017 at 5:44:12 AM PDT' ({timeZoneName: 'short', ...}) or Friday, July 21, 2017 at 5:44:08 AM Pacific Daylight Time ({timeZoneName: 'long', ...}).

What I've seen is the need for different time zone display names for generating a list of localized time zones for the user to choose from. Something like this: (cc @lwelti)

Also cc @mimckenna @alolita @dwbruhn for any additional thoughts...

---

Cc @srl295 in case he has any thoughts...

[caridy]

Holding off until we get more feedback from other users.

[alolita]

@rxaviers fwiw in the organizational use case, it is best practice to adhere to the names CLDR provides without localizing display names further for each timezone. This has been done for data maintainability and UI design standardization. Client side implementations could easily create a complex mapping between each timezone, standard display name and multiple local display names for the end user. It is up to the organization implementing localized names to extend a standard internally as well as maintain these localized names. I don't see why globalize would support this 🤔

[jungshik]

I listed what I think is good to add in my previous comment. Let me copy the list here again:

Z, ZZZZ : UTC offset ; -0800, GMT-0800
v, vvvv: short and long non-specific names: PT and Pacific Time (as opposed to PDT/PST and Pacific Daylight/Standard Time)
V, VV, VVV, VVVV: uslax, America/Los_Angeles, Los Angeles, Los Angeles Time

UTC offset (Z*) is sometimes handy for those who just care about the offset. v and vvvv are handy when one does not care about DST. V* are nice for Olson id-based display (which is easier to some users not familiar with foreign timezone names).

I'm sitting at the Unicode conference talk on Globalize.js and timezone support. In one of slides, the lack of support for 'v*' variants in Ecma 402 is called out (the comparison chart between Globalize.js and Ecma402).

It's a bit hard to come with 'named styles' for all the above without turning them to 'too long and too hard-to-remember names'. If it turns out to be too hard to come up with good names for all the above, we may block this on 'skeleton' support (Globalize.js seems to support it via 'raw:' - not sure if Globalize.js is a skeleton or a pattern).

[rxaviers]

@jungshik, quick reply: in Globalize, raw means pattern; we encourage users to favor skeleton over passing a pattern with raw, but we offer it anyway for the cases where it's needed.

[jungshik]

@rxaviers : Thanks for the clarification. I think using 'raw' instead of 'pattern' is a good idea because that way we can reduce the user confusion between 'skeleton' and 'pattern'.

[gibson042]

I don't care what name is used, but we now have a strong motivation to introduce a way to include the IANA time zone name in string representations, because that is inherently part of Temporal and @pipobscure is introducing a rather cumbersome workaround in the polyfill to detect the system time zone.

[littledan]

@gibson042 I'm confused about this; you can always find the IANA timezone name with an Intl.DateTimeFormat object obj using obj.resolvedOptions().timeZone. Why would you need that to be part of the locale-dependent string returned by format?

[gibson042]

Ah, both of us somehow missed that. I still think it would be useful for DateTimeFormat to return strings that can be successfully parsed as ZonedDateTime objects (e.g., "2019-04-01T13:18:42-04:00[America/New_York]"), but Intl.DateTimeFormat().resolvedOptions().timeZone reduces the urgency of that request.

[littledan]

I think that should be done by a different API. It's not a locale-dependent operation. At the risk of sounding like a broken record, could we pursue this feature as part of the Temporal proposal?

[pipobscure]

ZonedDateTime.prototype.toString
and
ZonedDateTime.fromString

do exactly that. So there is no need to put this into the Formatters. So I agree with @littledan on this

[FrankYFTang]

related info https://unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names

[srl295]

VVVV would be nice to have, "Los Angeles Time" or "Paris Time" is nice and clear without getting into obscure abbreviations.
I support the list here #119 (comment)

Z, ZZZZ : UTC offset ; -0800, GMT-0800
v, vvvv: short and long non-specific names: PT and Pacific Time (as opposed to PDT/PST and Pacific Daylight/Standard Time)
V, VV, VVV, VVVV: uslax, America/Los_Angeles, Los Angeles, Los Angeles Time

Also, v/vvvv (above) avoids saying anything about the daylight stuff, so it shows 'wall time'.

Straw Proposal:

timeZoneName	CLDR pattern	example
offset	Z	-0800
longOffset	ZZZZ	GMT-0800
shortWall	v	PT
longWall	vvvv	Pacific Time
locode	V	uslax
id	VV	America/Los_Angeles
location	VVV	Los Angeles
longLocation	VVVV	Los Angeles TIme

[FrankYFTang]

OK, here is what I got from my v8 prototype according to what srl295 proposed:

$ out/x64.release/d8 --harmony_intl_more_timezone
V8 version 8.7.0 (candidate)
d8> let timeZoneNames = ["short", "long", "offset", "longOffset", "shortWall", "longWall", "locode", "id", "location", "longLocation"];
undefined
d8> timeZoneNames.forEach(function(timeZoneName) { print((new Date()).toLocaleTimeString("en", {timeZoneName}))});
5:39:14 PM PDT
5:39:14 PM Pacific Daylight Time
5:39:14 PM -0700
5:39:14 PM GMT-07:00
5:39:14 PM PT
5:39:14 PM Pacific Time
5:39:14 PM uslax
5:39:14 PM America/Los_Angeles
5:39:14 PM Los Angeles
5:39:14 PM Los Angeles Time
undefined
d8> timeZoneNames.forEach(function(timeZoneName) { print((new Date()).toLocaleTimeString("zh-Hant", {timeZoneName}))});
下午5:39:40 [PDT]
下午5:39:40 [太平洋夏令時間]
下午5:39:40 [-0700]
下午5:39:40 [GMT-07:00]
下午5:39:40 [PT]
下午5:39:40 [太平洋時間]
下午5:39:40 [uslax]
下午5:39:40 [America/Los_Angeles]
下午5:39:40 [Los Angeles]
下午5:39:40 [Los Angeles時間]
undefined
d8> timeZoneNames.forEach(function(timeZoneName) { print((new Date()).toLocaleTimeString("fr", {timeZoneName}))});
17:40:55 UTC−7
17:40:55 heure d’été du Pacifique
17:40:55 -0700
17:40:55 UTC−07:00
17:40:55 heure : Los Angeles
17:40:55 heure du Pacifique nord-américain
17:40:55 uslax
17:40:55 America/Los_Angeles
17:40:55 Los Angeles
17:40:55 heure : Los Angeles
undefined
d8> timeZoneNames.forEach(function(timeZoneName) { print((new Date()).toLocaleTimeString("ko", {timeZoneName}))});
오후 5시 41분 31초 GMT-7
오후 5시 41분 31초 북미 태평양 하계 표준시
오후 5시 41분 31초 -0700
오후 5:41:31 GMT-07:00
오후 5:41:31 Los Angeles 시간
오후 5:41:31 북미 태평양 시간
오후 5시 41분 31초 uslax
오후 5:41:31 America/Los_Angeles
오후 5:41:31 Los Angeles
오후 5:41:31 Los Angeles 시간
undefined

Looking from the output, "locode" and "id" looks pretty useless. I am not supporting adding that two.

For anyone want to take a look my prototype cl
https://chromium-review.googlesource.com/c/v8/v8/+/2425328

[FrankYFTang]

We should discuss this in the coming ECMA402 meeting

1. Should we try to extend timeZoneName?
2. Should this be addressed by a PR or a proposal?
3. If Parsing APIs #1 is yes, what should be added (I propose limit to "offset", "longOffset", "shortWall" ,"longWall", "location", "longLocation", but not id nor locode)
4. Are these property value the best choice? or do we have better name for these?

[srl295]

+1 but why not Id or locode?

…

On Tue, Sep 22, 2020 at 7:54 PM Frank Yung-Fong Tang < ***@***.***> wrote: We should discuss this in the coming ECMA402 meeting 1. Should we try to extend timeZoneName? 2. Should this be addressed by a PR or a proposal? 3. If #1 <#1> is yes, what should be added (I propose limit to "offset", "longOffset", "shortWall" ,"longWall", "location", "longLocation", but not id nor locode) 4. Are these property value the best choice? or do we have better name for these? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGQZM4QNWHL3RZH6M4GPK3SHFBNNANCNFSM4C3R6CSQ> .

[FrankYFTang]

+1 but why not Id or locode?

Because I cannot believe anyone in the word would prefer to see time print out as below as a natural way to express time.
"
5:39:14 PM uslax
5:39:14 PM America/Los_Angeles
"

[pipobscure]

I see your point regarding id though I’m absolutely sure you’re off for locode because it’s a normalized way to express timezones which is so universally used as to be common.

[srl295]

Frank, It's probably unlikely among people that aren't too close to things. uslax is also an input (-u extension) in CLDR. Anyway, perhaps id / locode should be 'getters' rather than format option in this case. Would be great to have some access, even if it's not part of format.

[FrankYFTang]

I see your point regarding id though I’m absolutely sure you’re off for locode because it’s a normalized way to express timezones which is so universally used as to be common.

could you list 5 real web page (or application screen shot) showing that in kind of time zone format to users? If you can do that, I will agree.

[FrankYFTang]

perhaps id / locode should be 'getters' rather than format option in this case.

What does this mean (of be a getters)? could you show me some example JS code to express what you wish the API would do for that?

[srl295]

perhaps id / locode should be 'getters' rather than format option in this case.

What does this mean (of be a getters)? could you show me some example JS code to express what you wish the API would do for that?

I'm not sure of the right API location. Maybe it would be part of resolvedOptions even, since it's not wall-time specific. Roughly:

const d = new Date(); // date for the zone info
const {locode, id} = fmt.zoneInfoFor(d);
=>  locode: 'uslax', id: 'America/Los_Angeles`

the date is needed because of historcial zones

[FrankYFTang]

During ECMA402 meeting, we decide Frank will draft a Stage 0 proposal and talk next time.

[FrankYFTang]

I see your point regarding id though I’m absolutely sure you’re off for locode because it’s a normalized way to express timezones which is so universally used as to be common.

My point is neither id nor locode are GENERATED as a formatted result to express a time zone. They are widely used as Input Parameter for sure. But we are talking about what options should be supported to output the value of timezone into a human readable text. And I don't see neither id nor loccode were used in that context anywhere.

[srl295]

perhaps id / locode should be 'getters' rather than format option in this case.

What does this mean (of be a getters)? could you show me some example JS code to express what you wish the API would do for that?

I meant as getters on resolvedOptions. i.e. my default zone is Central Time, so I could imagine a resolvedOptions taking into account environment defaults, the -u-tz subtag, etc etc and returning { timeZone: 'America/Chicago', timeZoneLocode: 'uschi' }. That's the concept. (of course timeZone is already there)

[FrankYFTang]

OK, I put together a Stage 0 propose and will put on the ECMA402 Monthly agenda for the coming Thursday. Please move the discussion there and come to the Th meeting to discuss if you care.
https://github.com/FrankYFTang/proposal-intl-extend-timezonename

[FrankYFTang]

perhaps id / locode should be 'getters' rather than format option in this case.

What does this mean (of be a getters)? could you show me some example JS code to express what you wish the API would do for that?

I meant as getters on resolvedOptions. i.e. my default zone is Central Time, so I could imagine a resolvedOptions taking into account environment defaults, the -u-tz subtag, etc etc and returning { timeZone: 'America/Chicago', timeZoneLocode: 'uschi' }. That's the concept. (of course timeZone is already there)

so far the "tz" in the "-u-" extension is ignored per:
https://ecma-international.org/ecma-402/#sec-intl.datetimeformat-internal-slots
"
NOTE 1
Unicode Technical Standard 35 describes three locale extension keys that are relevant to date and time formatting, "ca" for calendar, "tz" for time zone, "hc" for hour cycle, and implicitly "nu" for the numbering system of the number format used for numbers within the date format. DateTimeFormat, however, requires that the time zone is specified through the "timeZone" property in the options objects.
"