Specify well-formed values for timezones, calendars & units#1104
Specify well-formed values for timezones, calendars & units#1104
Conversation
aphillips
left a comment
aphillips
left a comment
There was a problem hiding this comment.
Minor comments. Generally looks very good. I support the direction this is taking.
Co-authored-by: Addison Phillips <[email protected]>
|
A couple of comments.
Can you sketch out how that would be done? (In general, the more limitations the spec has compared to MF1, the harder it is to make a case for migration to MF2.) Cf. @sffc, @robertbastian |
The formatting of timezones is outside the scope of this PR; for that we've
As noted in previous discussions, e.g. #962 (comment), we have concerns about the use of short ids for interchange beyond ICU implementations. Therefore, it would be most appropriate for Someone™ to start drafting If this Someone™ ends up being the MFWG rather than the ICU-TC, then we should probably consider using the This distinction is intended to ensure that interoperable non-ICU implementations of Unicode MessageFormat remain possible. |
This comment was marked as off-topic.
This comment was marked as off-topic.
True, that would be a way to support the additional features. I should have phrased my comment differently; the main point is that lacking those features will imped migration. |
gibson042
left a comment
gibson042
left a comment
There was a problem hiding this comment.
I am also happy with this direction.
| a _Bad Operand_ error is emitted and the default time zone is used to format the _expression_. | ||
|
|
||
| If the _resolved value_ of the _operand_ does not include a time zone or offset, | ||
| the _resolved value_ of the `timeZone` _option_ is used as its time zone. |
There was a problem hiding this comment.
It's better to have this language than not, but it doesn't answer #961.
| > [!NOTE] | ||
| > A date/time type encapsulating a Unix time is considered to include UTC as its time zone. | ||
|
|
There was a problem hiding this comment.
If this is talking about Java Date, it seems better to use the local time zone than UTC.
Co-authored-by: Richard Gibson <[email protected]> Co-authored-by: Eemeli Aro <[email protected]>
6 participants
Closes #935
Closes #936
See also #961 (comment)
Closes #962
As resolved on this week's call, the options for which we accept values defined elsewhere should all be spec'd as "well-formed" rather than "valid". As we do not mandate that all well-formed values are accepted without error, or that the errors emitted for "not well-formed" and "not valid" are different from each other, this allows for a linter/validator to detect not-well-formed values early, while not requiring a formatting implementation to differentiate well-formed-but-not-valid from not-well-formed values.
While the spec text does not make mention of Unicode short time zone identifiers, it should be noted that all such values are technically well-formed time zone identifiers according to RFC 9557. This means that an implementation could support such values, but they would probably not work in all implementations. If we'd like to discourage this, I think including a non-normative note to that effect might be appropriate (suggestions for exact text are most welcome).
This PR also addresses #961 (comment) by defining the behaviour when formatting date/time values that do not include a time zone.