#Extend TimeZoneName Option Proposal S4

#Extend TimeZoneName Option Proposal

#Stage

Stage 3

• Advanced to Stage 1 in TC39 2021-01-25~28 meeting.
• 2021-04-08 ECMA402 meeting agree to proceed to TC39 for Stage 2
  • Rename (short|long)GMT to (short|long)Offset
• Advanced to Stage 2 in TC39 2021-04 meeting.
• Philip Chimento and Rick Button (assisted by Ujjwal) signed up to be Stage 3 reviewers
• Advanced to Stage 3 in TC39 2021-05 meeting.
• Update during Stage 3 in TC39 2021-07 meeting
• Slide for Stage 4 Advancement for TC39 2021-Dec meeting

#Champion

• Frank Tang @FrankYFTang

#Stage 3 reviewers (needed during stage 2)

• Philip Chimento @ptomato
• Rick Button @rickbutton

#Editor

• TBD

#Scope

Extend the timeZoneName option in Intl.DateTimeFormat object to support more formatted options.

#Background

Prior Discussion: ECMA402#119 DateTimeFormat: consider adding more timezone display options

Ref: UTS35 - "7 Using Time Zone Names"

#Updated Proposal - add 4 new formats only

Note: Here is how I get the above number

$ cd icu/icu4c/source/data/zone
$ egrep "sg\{" *|cut -d\" -f2 |wc
    332     333    1719
$ egrep "sg\{" *|cut -d\" -f2 | gzip -f |wc -c
311
$ egrep "lg\{" *|cut -d\" -f2 |wc 
  10047   24026  278103 
$ egrep "lg\{" *|cut -d\" -f2 | gzip -f |wc -c
69526
$ egrep "gmt.*Format\{" *|cut -d\" -f2 |wc
    263     284    1826
$ egrep "gmt.*Format\{" *|cut -d\" -f2 | gzip -f |wc -c
392

#Tracking

• Mozilla Tracking Bug
• V8 Tracking Bug
  • V8 is now implemented behind the flag --harmony_intl_more_timezone

#Output from V8 of the updated proposal

$ out/x64.release/d8 --harmony_intl_more_timezone
V8 version 8.9.0 (candidate)
d8> let timeZoneNames = ["short", "long", "shortOffset", "longOffset", "shortGeneric", "longGeneric"];
d8> timeZoneNames.forEach(function(timeZoneName) { print(timeZoneName + ": " + (new Date()).toLocaleTimeString("en", {timeZoneName}))});
d8> timeZoneNames.forEach(function(timeZoneName) { print(timeZoneName + ": " + (new Date()).toLocaleTimeString("en", {timeZoneName}))});
short: 12:27:10 PM PST
long: 12:27:10 PM Pacific Standard Time
shortOffset: 12:27:10 PM GMT-8
longOffset: 12:27:10 PM GMT-08:00
shortGeneric: 12:27:10 PM PT
longWall: 12:27:10 PM Pacific Time


d8> timeZoneNames.forEach(function(timeZoneName) { print(timeZoneName + ": " + (new Date()).toLocaleTimeString("zh-Hant", {timeZoneName}))});
short: 下午12:26:20 [PST]
long: 下午12:26:20 [太平洋標準時間]
shortOffset: 下午12:26:20 [GMT-8]
longOffset: 下午12:26:20 [GMT-08:00]
shortGeneric: 下午12:26:20 [PT]
longGeneric: 下午12:26:20 [太平洋時間]


d8> timeZoneNames.forEach(function(timeZoneName) { print(timeZoneName + ": " + (new Date()).toLocaleTimeString("en", {timeZoneName, timeZone: "Asia/Calcutta"}))});
short: 1:54:56 AM GMT+5:30
long: 1:54:56 AM India Standard Time
shortOffset: 1:54:56 AM GMT+5:30
longOffset: 1:54:56 AM GMT+05:30
shortGeneric: 1:54:56 AM India Time
longGeneric: 1:54:56 AM India Standard Time

See possible options removed due to size concern in archived README.md

#Stage Advancement Planning

#Entrance Criteria For Stage 2

• Initial spec text https://tc39.es/proposal-intl-extend-timezonename/ DONE
• All Entrance Criteria for State 1 DONE
• Acceptance Signifies: “The committee expects the feature to be developed and eventually included in the standard”

#Entrance Criteria For Stage 1

• Identified “champion” who will advance the addition: DONE- @FrankYFTang
• Prose outlining the problem or need and the general shape of a solution DONE
• Illustrative examples of usage DONE
• High-level API DONE
• Discussion of key algorithms, abstractions and semantics DONE
• Identification of potential “cross-cutting” concerns and implementation challenges/complexity DONE
• A publicly available repository for the proposal that captures the above requirements: DONE https://github.com/tc39/proposal-intl-extend-timezonename/
• Acceptance Signifies: “The committee expects to devote time to examining the problem space, solutions and cross-cutting concerns”