[FEEDBACK] Don't include a time zone option, or be strict if you do

[sffc]

Conflicts between time zones coming from different sources has been a persistent pain point that the Temporal champions have worked to avoid. It would be nice for MessageFormat to not repeat the same situation.

The problem is, what do you do if someone passes a ZonedDateTime to a MessageFormat configured with a :datetime field with a timeZone option? There are two time zones to choose from, and none of the resolution options are great:

1. Use input time zone
   • Bad: the time zone in the message is not respected
2. Use message zone with conversion
   • Bad: requires TZDB and mutates data in potentially unexpected ways (e.g. daylight saving time)
3. Use message zone without conversion
   • Bad: displaying an instant that differs from the input

In the Temporal specification, we handle the problem by disallowing a ZonedDateTime to be passed as input.

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

However, a better design would be to forbid the formatter itself from having a time zone option, a luxury we didn't have when integrating Temporal with the pre-existing Intl.DateTimeFormat.

[aphillips]

(as individual contributor)

Omitting support for time zones is super unhelpful for users, who will want to format date and time values and who have needs for managing the time zone used (or not used, in the case of floated or "plain" values) and who do not always have control over the format of the incoming value.

A ZonedDateTime is a moment attached to the timeline. It is a clearly identified moment in time with no ambiguity. It can be formatted for display, and users will want to pass it for formatting. Otherwise, what is the point?

A user can have a ZonedDateTime and wish to use a different time zone for displaying the value. Or they might have done as you seem to be suggesting and have an Instant--in which case they had better have a timeZone option to allow for proper display! The same thing goes for classical date/time values (such as Date), which crave a time zone for proper expression. Or I could make a PlainDateTime out of the ZDT, but then I can't show the time zone with the time value (which is a loss of precision).

The timeZone option allows the message author to override the zone when it is present and perform the conversion (it also allows the value to be "floated"--removed from the timeline so that the digits are constant). Does conversion require the TZDB? Yes, but then the implementation already needs the TZDB in order to render date and time values that include a time zone or to format incremental time values.

Note that the timeZone option does not "mutate the data". The resolved value of an expression might be a different ZonedDateTime than the input, but the input cannot itself be mutated.

Is there some danger that users will do Bad Things using timeZone? Sure. But the tripping hazards seem far smaller to me than providing no control and requiring users to apply everything in the cookbook to do simple formatting.

---

(as chair)

Please note that this option is PROPOSED for 2.0 and is still open to change. Please file normal issues or (better yet) submit a design document for what we should do.

[sffc]

Does conversion require the TZDB? Yes, but then the implementation already needs the TZDB in order to render date and time values that include a time zone or to format incremental time values.

ICU4X formats datetimes without access to full TZDB. This is possible so long as the datetime is annotated with an offset from elsewhere in the stack. For example, the server can calculate the offset from TZDB and send an annotated IXDTF string to a client running ICU4X that does not need TZDB to format it.

[sffc]

If you insist on having If the WG feels it is beneficial to have a timeZone option, I would like it to have the behavior where it is applied only for Instant formatting. The spec should say something like:

1. The timeZone option should be used only if the input value is an instant in time, such as number of seconds since UNIX epoch, not associated with a particular time zone
2. If the timeZone option is specified and the input is any other type, such as a ZonedDateTime or PlainDateTime, an input error should be thrown

[aphillips]

@sffc notes:

I would like it to have the behavior where it is applied only for Instant formatting.

There are a number of problems here.

One is: MF2 does not have types. We can specify that implementations are allowed to do certain things or allowed to emit certain errors.

If the timeZone option is specified and the input is any other type, such as a ZonedDateTime or PlainDateTime, an input error should be thrown

I agree with your earlier assertion that the operations in question should be carefully defined.

It cannot be an "input error" because there is no such thing in MF2. It can be a Bad Option error or an Unsupported Operation error.

I might be convinced in the case of ZDT, but I'm having a hard time agreeing in the case of PDT. There are obviously different ways that such conversions can occur (does one interpret the PDT 2024-11-25T00:00:00 as being midnight in the requested zone or as being midnight in UTC and the zone's offset adjusting the value?). Specifying these is useful and valuable.

People want timekeeping to be simpler to use, not filled with arduous details.

In any case, I suspect the action item here is for me to go back and write a design document for this option so that we color in all of the details prior to finalizing it (which might include removing or disabling bits of it)

[macchiati]

A couple of comments:

If I supply an input parameter like $t being an implementation-defined datatype {datetime=2025-01-21T9:30 timezone=America/Los_Angeles} to the message:

{{The time in Berlin is {$t :datetime timezone=|Europe/Berlin|}}}

I would expect to see the formatted datetime for 2025-01-21T18:30, not 2025-01-21T9:30.

The same with {datetime=2025-01-21T9:30Z}.

This is then different than supplying a currency option to :currency; that needs to be illegal because currencies are not convertible.

A system might also have two separate input parameters:

$t being{datetime=2025-01-21T9:30}
$z being "America/Los_Angeles"

and formatting

{{The time is {$t :datetime timezone=$z}}}

[sffc]

I would expect to see the formatted datetime for 2025-01-21T18:30, not 2025-01-21T9:30.

(as chair of ICU4X-TC)

That's fair; I just want to emphasize that time zone conversion is not free and takes a large amount of data (the TZDB). We have done a pretty good job of keeping MF2 dependencies minimal and I would really like if we didn't add TZDB as a requirement.

[sffc]

It cannot be an "input error" because there is no such thing in MF2. It can be a Bad Option error or an Unsupported Operation error.

This doesn't make a lot of sense to me. What kind of error do I get when I pass the string "hello world" as an input to be formatted as a date? Or a Symbol or a HashMap or some other nonsensical type? You can throw the same type of error if the type to be formatted contains a time zone.

[eemeli]

What kind of error do I get when I pass the string "hello world" as an input to be formatted as a date? Or a Symbol or a HashMap or some other nonsensical type?

Probably Bad Operand.

You can throw the same type of error if the type to be formatted contains a time zone.

If the operand were formattable without a timeZone option set, it would probably be more appropriate to emit an Unsupported Operation error.

It would probably be a good idea to include something like what we have under Unit Conversion for timeZone as well:

message-format-wg/spec/registry.md

Lines 791 to 794 in ec9089d

	Implementations MAY support conversion to the locale's preferred units via the `usage` _option_.
	Implementing this _option_ is optional.
	Not all `usage` values are compatible with a given unit.
	Implementations SHOULD emit an _Unsupported Operation_ error if the requested conversion is not supported.