Existing DateTimeFormat objects don't reflect changes in the system time zone

[ptomato]

In InitializeDateTimeFormat step 30, if an Intl.DateTimeFormat object is created without a timeZone in its options argument, it'll use the current system time zone as retrieved from DefaultTimeZone. However, this value isn't guaranteed to remain consistent for the lifetime of the process. For example, the user may travel to a different part of the world and update their time zone, while any DateTimeFormat objects in running processes would continue to format according to their old time zone.

Essentially the question is, should an omitted timeZone option mean:

1. Create a formatter that formats in the current time zone as of the time of the object creation, or
2. Create a formatter that formats in the current time zone as of the time of formatting?

This may pose a problem with Temporal.ZonedDateTime in the future. Say, a web page from time to time updates a UI element using a cached formatter created with new Intl.DateTimeFormat(locale, { dateStyle: 'full', timeStyle: 'full' }) object, by formatting the result of Temporal.Now.zonedDateTime(). If the user's time zone according to DefaultTimeZone changes, the ZonedDateTime's time zone and the formatter's time zone will no longer agree. In that case, the programmer would have to know not to cache the formatter object, which is not obvious.

I tested this with recent Firefox and Chromium, which both follow the spec.

[justingrant]

Without knowing about the current spec, I'd have guessed that cached formatters would retain the time zone at construction time, as well as the locale, calendar, etc. Otherwise, IMO it'd be unexpected for resolvedOptions() to change its results over time.

Therefore, IMO caching a formatter should be no different than caching any other object like a ZonedDateTime, meaning it retains the content it had when it was cached.

If a developer wants to use the latest values, then they can create a new formatter.

If this proves to be a problem in the wild, then a future proposal could add an timeZone: 'auto' option which automatically fetches the system time zone before each format call.

[justingrant]

Thinking about this a bit more, I assume that there's a precedent in how other user-changeable settings (like locale) are handled when they're not specified explicitly by the caller. Maybe time zone should just match that existing behavior?

[sffc]

Interesting. I guess I'm a bit worried about totally reasonable-looking call sites such as

const formatter = new Intl.DateTimeFormat();
foo.addEventListener("click", () => {
    bar.innerText = formatter.format(Temporal.Now.zonedDateTimeISO());
}, false);

[ptomato]

Yeah, that's exactly the case I was wondering about. Other than that, I think it's not a problem to resolve the time zone at construction time.

[ljharb]

Wouldn't Temporal.Now.zonedDateTimeISO() provide the current timezone at click time, which would override whatever timezone the formatter had set?

[sffc]

Wouldn't Temporal.Now.zonedDateTimeISO() provide the current timezone at click time, which would override whatever timezone the formatter had set?

https://tc39.es/proposal-temporal/#sec-temporal-handledatetimevaluetemporalzoneddatetime

6. If dateTimeFormat.[[TimeZone]] is not equal to DefaultTimeZone(), and timeZone is not equal to dateTimeFormat.[[TimeZone]], then
   a. Throw a RangeError exception.

[sffc]

Maybe the behavior should be for DTF to just always use the ZDT's time zone when formatting. It already is flattening the ZDT to a timestamp. Actually, this might already be a bug, because I don't see where ZDT's time zone gets retained in the first case when dateTimeFormat.[[TimeZone]] is equal to DefaultTimeZone()

[ptomato]

The latter is indeed an existing bug which tc39/proposal-temporal#2479 fixes, one of the normative changes we are presenting next week to TC39.

[justingrant]

Ahh, OK now I think I understand the problem. I'm going to try to restate it here to make sure I'm getting it.

Sounds like there are really two cases: formatting ZDT values and formatting non-ZDT values.

For both, the question is how to handle the case where the system time zone changes in between when the formatter was created vs. when a format method was called, AND when there was no timeZone option provided when the formatter was created.

For ZDT values, the issue is whether or not a RangeError should be thrown (per tc39/proposal-temporal#2479) because the new time zone conflicts with the old time zone, like Shane's example I'm copying here:

const formatter = new Intl.DateTimeFormat();
foo.addEventListener("click", () => {
    bar.innerText = formatter.format(Temporal.Now.zonedDateTimeISO());
}, false);

For non-ZDT values, the question is which time zone should be used: the system time zone at formatter construction, or the system time zone when the formatting method is called. Like this sample using Instant instead of ZDT:

const formatter = new Intl.DateTimeFormat();
foo.addEventListener("click", () => {
    bar.innerText = formatter.format(Temporal.Now.instant());
}, false);

Is this an accurate description of the issues?

[sffc]

I think good behavior would be (in pseudospec)

// In constructor
If options.timeZone is undefined,
    set dateTimeFormat.[[TimeZone]] to ~auto~.
Else,
    set dateTimeFormat.[[TimeZone]] to GetOption(...).

// In formatting function
Let timeZone be dateTimeFormat.[[TimeZone]].
If typeof date is ZonedDateTime,
    If timeZone is ~auto~, then
        set timeZone to date.timeZone.
    Else if timeZone != date.timeZone, then
        throw new RangeError.
Else if timeZone is ~auto~, then
    set timeZone to DefaultTimeZone().

[anba]

If typeof date is ZonedDateTime,
// [Omitted]
Else if timeZone is ~auto~, then
    set timeZone to DefaultTimeZone().

I don't think we should do this, because as noted in #750 (comment), that leads to returning inconsistent information w.r.t. resolvedOptions(). Or do you propose to also changing resolvedOptions() to always return the current time zone for ~auto~?

[justingrant]

Yep, that was part of my questions above: are the values returned by resolvedOptions() expected to be invariant for the lifetime of the formatter object, or are they expected to vary in response to changes in the system like the user changing their system's default locale, user changing their time zone, user changing their OS's internationalization settings, etc. ?

Before Temporal, what was the answer to that question?

[ptomato]

Temporal doesn't change anything here, because the Temporal.Instant example above applies equally well to Date:

const formatter = new Intl.DateTimeFormat();
foo.addEventListener("click", () => {
    bar.innerText = formatter.format(new Date());
}, false);

[sffc]

Maybe the behavior should be for DTF to just always use the ZDT's time zone when formatting. It already is flattening the ZDT to a timestamp. Actually, this might already be a bug, because I don't see where ZDT's time zone gets retained in the first case when dateTimeFormat.[[TimeZone]] is equal to DefaultTimeZone()

[ptomato]

The latter is indeed an existing bug which tc39/proposal-temporal#2479 fixes, one of the normative changes we are presenting next week to TC39.

[justingrant]

Ahh, OK now I think I understand the problem. I'm going to try to restate it here to make sure I'm getting it.

Sounds like there are really two cases: formatting ZDT values and formatting non-ZDT values.

For both, the question is how to handle the case where the system time zone changes in between when the formatter was created vs. when a format method was called, AND when there was no timeZone option provided when the formatter was created.

For ZDT values, the issue is whether or not a RangeError should be thrown (per tc39/proposal-temporal#2479) because the new time zone conflicts with the old time zone, like Shane's example I'm copying here:

const formatter = new Intl.DateTimeFormat();
foo.addEventListener("click", () => {
    bar.innerText = formatter.format(Temporal.Now.zonedDateTimeISO());
}, false);

For non-ZDT values, the question is which time zone should be used: the system time zone at formatter construction, or the system time zone when the formatting method is called. Like this sample using Instant instead of ZDT:

const formatter = new Intl.DateTimeFormat();
foo.addEventListener("click", () => {
    bar.innerText = formatter.format(Temporal.Now.instant());
}, false);

Is this an accurate description of the issues?

[sffc]

I think good behavior would be (in pseudospec)

// In constructor
If options.timeZone is undefined,
    set dateTimeFormat.[[TimeZone]] to ~auto~.
Else,
    set dateTimeFormat.[[TimeZone]] to GetOption(...).

// In formatting function
Let timeZone be dateTimeFormat.[[TimeZone]].
If typeof date is ZonedDateTime,
    If timeZone is ~auto~, then
        set timeZone to date.timeZone.
    Else if timeZone != date.timeZone, then
        throw new RangeError.
Else if timeZone is ~auto~, then
    set timeZone to DefaultTimeZone().

[anba]

If typeof date is ZonedDateTime,
// [Omitted]
Else if timeZone is ~auto~, then
    set timeZone to DefaultTimeZone().

I don't think we should do this, because as noted in #750 (comment), that leads to returning inconsistent information w.r.t. resolvedOptions(). Or do you propose to also changing resolvedOptions() to always return the current time zone for ~auto~?

[justingrant]

Yep, that was part of my questions above: are the values returned by resolvedOptions() expected to be invariant for the lifetime of the formatter object, or are they expected to vary in response to changes in the system like the user changing their system's default locale, user changing their time zone, user changing their OS's internationalization settings, etc. ?

Before Temporal, what was the answer to that question?

[ptomato]

Temporal doesn't change anything here, because the Temporal.Instant example above applies equally well to Date:

const formatter = new Intl.DateTimeFormat();
foo.addEventListener("click", () => {
    bar.innerText = formatter.format(new Date());
}, false);

[justingrant]

Agree, I was wondering about how it's expected to work today in a pre-Temporal world. Is it expected that the same formatter will return different results (either from format or from resolvedOptions) if the system changes in some way like changing the OS's locale or time zone? Or is it expected that, once created, a formatter object's output will be consistent for the life of the surrounding agent?

[ptomato]

Literally speaking, it's expected that the formatter's output is consistent, because that's what the spec says. That's also how the implementations work, at least the ones that I tried. However, I doubt many programmers have an expectation one way or the other because the OS's time zone changing is probably not a case that most people take into account.

[gibson042]

Agreed. The DateTimeFormat constructor is specified to concretely resolve options and return an instance that relies upon them, regardless of subsequent changes in the host environment.

[sffc]

OK, this is reasonable, and it's how the spec already works so we don't really need to get consensus in TG2 (thus I removed the "s: discuss" label).