Maximum precision of offset time zones

[gibson042]

Discussion in TG2 about tc39/ecma402#788 raised numerous concerns around allowing offset time zone precision to exceed minutes, which is the representable limit of https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-08.html#section-4 (see also tc39/ecma262#3087 ). Should Temporal similarly limit precision?

[justingrant]

#1699 and #1798 have previous discussion of nanoseconds precision for time zone offsets.

Seems like there are (at least) a few options here:

1. Convince implementers that nanoseconds (48 bits required) in time zone offsets is OK. Based on today's TG2 discussion, this seems unlikely to be successful; there was very strong pushback to making nanoseconds work with Intl.DateTimeFormat.
2. Reduce offset precision to minutes, to match IETF - 12 bits required.
3. Reduce offset precision to seconds, to match iCalendar - 18 bits required
4. Reduce offset precision to 0.01 second, to match the most granular offset in the IANA TZDB - 25 bits required
5. Keep nanoseconds precision for offsets in Temporal (and hence 262) but round to the nearest minute when storing in Intl.DateTimeFormat's internal slot.

Note that offsets and named time zones are mutually exclusive. This has advantages for storage because a single bit can be used to record whether it's an offset or a named zone, and the rest of the storage could be shared. There's particular advantage for minutes precision because it enables a time zone (regardless of named or offset) to be stored in 16 bits. 10 bits are already required to store named time zones, so minute-precision offsets could be added to any implementation without increasing the number of bytes needed to store a time zone. I think this is why the TG2 folks were so enthusiastic about minute precision.

struct TimeZone {
  // 0 means named time zone, 1 means offset
  int isOffset: 1;

  // If named zone: index into a static array of ~600 IANA names.
  // If offset zone: a signed number of minutes.
  int index: 12;
}

[michaelficarra]

How would a restriction to minute/second precision in offsets impact use of time zones with sub-minute/second offsets? I don't see how we could possibly choose anything less than the most granular timezone currently in TZDB, and the right choice seems to be that the offset precision should match the time representation precision (nanoseconds).

[FrankYFTang]

4. 0.01 second, to match the most granular offset in the IANA TZDB

Could you cite which TimeZone in IANA TZDE currently has such and which value is that?

I believe the information you stated here "0.01 second, to match the most granular offset in the IANA TZDB" is simply a FALSE statement. We should NOT based on such incorrect information in our decision making.

Here is what I did to prove that statement is FALSE:

$ wget https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz
$ gzip -dc tzdata-latest.tar.gz | tar -xf -
$ ls |egrep -v "README|NEWS|Makefile|CONTRIBUTING|SECURITY|LICENSE|calendars|.(html|gz|awk|tab)"|xargs egrep "^[^#]*[0-9]\.[0-9]"

There are no ouput

In the other hand, if you search for lines which got commented out

$ ls |egrep -v "README|NEWS|Makefile|CONTRIBUTING|SECURITY|LICENSE|calendars|.(html|gz|awk|tab)"|xargs egrep "[0-9]\.[0-9]"

You got 225 lines of comments which may have text referrring to value as small as 0.01 second, such as

northamerica:# Milne gives -5:28:50.45 for the observatory at Havana, -5:29:23.57

But these 0.01 second referrences are INSIDE comments, NOT for anything that "the most granular offset in the IANA TZDB" .

[FrankYFTang]

The iCalendar specification I bleieve is

       time-numzone = ("+" / "-") time-hour time-minute [time-second]

in https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.14

[FrankYFTang]

I simply do not understand how would the Temporal spec work with IETF in this current stage.

1. you can create a Temporal object with the timezone Offset set to nanoseconds,
2. then in https://tc39.es/proposal-temporal/#sec-temporal.timezone.prototype.tostring
   you could generate a TimeZone string with offset which have second as well as 9 digits fractional second

But this string does NOT fit the IETF grammar which only accept offset in
https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-08.html#name-abnf

time-zone         = "[" critical-flag
                        time-zone-name / time-numoffset "]"

time-numoffset are imported from Section 5.6 of [RFC3339], ALPHA and DIGIT from Appendix B.1 of [RFC5234].

and https://www.rfc-editor.org/rfc/rfc3339.html#section-5.6 stated

   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
...
   time-numoffset  = ("+" / "-") time-hour ":" time-minute

how could we then achieve any compatability with any other software follow this IETF grammar? any timezone offset with second or subsecond fraction will simply not fit the IETF grammar.

Did I missed anything?

[FrankYFTang]

The issue was introduced into ECMA262 in
tc39/ecma262#2781

I believe the UTCOffset defined in that PR is incorrect.

The grammar stated in
https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-08.html#name-abnf
only accept hour and minute in the timezone offset string, not second nor fractional second.

If temporal generate timezone by folllowing the grammar of https://tc39.es/ecma262/#sec-time-zone-offset-string-format

it will generate timezone string incompatabile with IETF spec
https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-08.html#name-abnf

[FrankYFTang]

I don't see how we could possibly choose anything less than the most granular timezone currently in TZDB

1. Why not? If they use any zonename in TZDB, they do not need to use utc offset.
2. The REAL "most granular timezone currently in TZDB" is second, not 0.01 second. 0.01 second value is only mentioned in the COMMENTS of the file inside TZDB, NOT as real data values in the TZDB. You cannot find any TZDB real value referring to 0.01 second precision. Regardless it is relevant or not.

[anba]

4. 0.01 second, to match the most granular offset in the IANA TZDB

Could you cite which TimeZone in IANA TZDE currently has such and which value is that?

Subseconds precision is only available in the vanguard format. In the vanguard format, offsets with subseconds precision use the comment marker #STDOFF, see for example Europe/Dublin.

Relevant commit: eggert/tz@4f8ac11

Subseconds precision is considered experimental according to this comment, though.

[gibson042]

Did I missed anything?

@FrankYFTang I believe you have correctly identified an issue. Looking at TemporalZonedDateTimeToString, we see

• step 10.b: Let offsetString be ! FormatISOTimeZoneOffsetString(offsetNs).
• step 12.a: Let timeZoneIdentifier be ? ToTemporalTimeZoneIdentifier(timeZone).
• step 12.b: Let timeZoneString be the string-concatenation of the code unit 0x005B (LEFT SQUARE BRACKET), flag, timeZoneIdentifier, and the code unit 0x005D (RIGHT SQUARE BRACKET).
• step 14: Return the string-concatenation of dateTimeString, offsetString, timeZoneString, and calendarString.

FormatISOTimeZoneOffsetString avoids nonconformance with the RFC 3339 date-time part of an IXDTF date-time-ext by rounding nanoseconds to ±hh:mm with ties away from zero, but ToTemporalTimeZoneIdentifier just echoes back a slot value that could itself include seconds and even fractional seconds from FormatTimeZoneOffsetString via ToTemporalTimeZoneSlotValue in the Temporal.ZonedDateTime constructor. To be concrete,

(new Temporal.ZonedDateTime(0n, "+00:00:00.123456789")).toString();
// => "1970-01-01T00:00:00.123456789+00:00[+00:00:00.123456789]"

in which the bracketed time-zone suffix is too precise to conform with IXDTF syntax.

[FrankYFTang]

4. 0.01 second, to match the most granular offset in the IANA TZDB

Could you cite which TimeZone in IANA TZDE currently has such and which value is that?

Subseconds precision is only available in the vanguard format. In the vanguard format, offsets with subseconds precision use the comment marker #STDOFF, see for example Europe/Dublin.

Relevant commit: eggert/tz@4f8ac11

Subseconds precision is considered experimental according to this comment, though.

Thanks @anba about that
The comment is quit interesting:

  # Normally, prefer whole seconds.  However, prefer subseconds
  # if generating vanguard form and the otherwise-undocumented
  # VANGUARD_SUBSECONDS environment variable is set.
  # This relies on #STDOFF comment lines in the data.
  # It is for hypothetical clients that support UT offsets that are
  # not integer multiples of one second (e.g., Europe/Lisbon, 1884 to 1912).
  # No known clients need this currently, and this experimental
  # feature may be changed or withdrawn in future releases.

In particular the words "otherwise-undocumented", "hypothetical clients", "No known clients need", and "may be changed or withdrawn in future releases".

[justingrant]

Meeting 2023-06-08: We'll change granularity of offset time zones to minutes, because:

• Lack of clear use cases and interoperability requirements for built-in, sub-minute offset time zones.
• Custom time zones can be created with more granular precision if needed.
• Making this change was strongly requested by implementers because it shrinks the storage requirements for Temporal.TimeZone from 49 bits to 12-13 bits.

Details: (feedback welcome!)

• In the TimeZone constructor and ToTemporalTimeZoneSlotValue, if seconds are present in an offset string input, a RangeError will be thrown even if seconds are zero. This enables a possible future extension in a later proposal, if needed.
• SystemTimeZoneIdentifier (the new name of DefaultTimeZone) will be required to be constrained to minutes precision if its result is an offset string. AFAIK no implementation currently returns offset strings from this AO, so although this is theoretically a breaking change, in reality it's not.
  • While we're making this change to SystemTimeZoneIdentifier's offset-string behavior, we'll also require that offset strings returned from that AO are in their normal form, e.g. -05:00 not -0500 nor -05.

Otherwise, nothing else will change:

• Built-in named time zones can still use sub-minute offsets from TZDB. For example:

zdt = Temporal.ZonedDateTime.from('1970-01-01[Africa/Monrovia]')
// => 1970-01-01T00:00:00-00:45[Africa/Monrovia]
zdt.offset
// => '-00:44:30'

• The resolution of built-in time zones' offsets continues to be either seconds or hundredths of a second, depending on the implementation's way of building and extracting TZDB data, as discussed above. (TZDB build behavior is currently implementation-defined.)
• Custom timezones can still return sub-minute values from getOffsetNanosecondsFor, and Temporal should still perform internal offset calculations in nanoseconds to support these custom time zones.
• The ZonedDateTime.p.offset property will continue to show the full precision returned by its time zone's getOffsetNanosecondsFor, which may include seconds or smaller units for custom time zones or built-in named time zones.
• When offset is used in a property bag input (e.g. to ZDT.from), nanoseconds resolution will continue to be supported.
• Parsing of offsets in the RFC3339 portion of ISO strings (the offset NOT inside brackets) should continue to behave as it does today, which is that Temporal objects (but not Date!) accept timestamp offsets down to nanoseconds. We'll add some spec text to clarify that this behavior intentionally exceeds the precision of IXDTF.
  • When parsing IXDTF strings, if the RFC3339 offset has non-zero seconds (or smaller) units but the bracketed offset does not (because we're limiting offset time zone identifiers to minute resolution), then the offset: 'reject' option will continue throwing a RangeError because the offsets don't match. There's also no change in behavior for other offset option values: use, ignore, and prefer.