-
-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define function composition for date/time values #814
Changes from all commits
ca22a2c
30d022b
0cc8eef
dc776e1
2242035
3d335fe
05040e3
93d0794
54fa33e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -597,6 +597,11 @@ output. | |
If both are specified, a _Bad Option_ error MUST be emitted | ||
and a _fallback value_ used as the _resolved value_ of the _expression_. | ||
|
||
If the _operand_ of the _expression_ is an implementation-defined date/time type, | ||
it can include _style options_, _field options_, or other option values. | ||
These are included in the resolved option values of the _expression_, | ||
with _options_ on the _expression_ taking priority over any option values of the _operand_. | ||
|
||
> [!NOTE] | ||
> The names of _options_ and their _values_ were derived from the | ||
> [options](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/resolvedOptions#description) | ||
|
@@ -696,7 +701,15 @@ are encouraged to track development of these options during Tech Preview: | |
- valid [Unicode Number System Identifier](https://cldr-smoke.unicode.org/spec/main/ldml/tr35.html#UnicodeNumberSystemIdentifier) | ||
- `timeZone` (default is system default time zone or UTC) | ||
- valid identifier per [BCP175](https://www.rfc-editor.org/rfc/rfc6557) | ||
|
||
|
||
#### Composition | ||
|
||
When an _operand_ or an _option_ value uses a _variable_ annotated, | ||
directly or indirectly, by a `:datetime` _annotation_, | ||
its _resolved value_ contains an implementation-defined date/time value | ||
of the _operand_ of the annotated _expression_, | ||
together with the resolved options values. | ||
|
||
### The `:date` function | ||
|
||
The function `:date` is used to format the date portion of date/time values. | ||
|
@@ -720,6 +733,19 @@ The function `:date` has these _options_: | |
- `medium` (default) | ||
- `short` | ||
|
||
If the _operand_ of the _expression_ is an implementation-defined date/time type, | ||
it can include other option values. | ||
Any _operand_ option values matching the `:datetime` _style options_ or _field options_ are ignored, | ||
as is any `style` option. | ||
Comment on lines
+738
to
+739
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be better to list the options that are are transitive rather than those that are not. I think the default probably should be that the operand and option list are not transitive, so that functions carefully list those that are. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we do that, then how do we avoid being proscriptive of the fields that an implementation might want to include in describing the locale options that are relevant to the date's formatting? Or would doing so be intentional and somehow beneficial? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think probably there are three things:
The last category mostly consists of (hopefully namespaced) implementation-specific options. Future additions to the standard fall into the first two categories. So I guess I'm saying I retract my original comment, but am looking for us to be more formal about how we implement this. Every option should clearly say which of the three (MUST/MUST NOT/MAY) it is, with MAY being strongly discouraged (i.e. non-existant) in the default registry and options being considered for RGI. |
||
|
||
#### Composition | ||
|
||
When an _operand_ or an _option_ value uses a _variable_ annotated, | ||
directly or indirectly, by a `:date` _annotation_, | ||
its _resolved value_ is implementation-defined. | ||
An implementation MAY emit a _Bad Operand_ or _Bad Option_ error (as appropriate) | ||
when this happens. | ||
|
||
### The `:time` function | ||
|
||
The function `:time` is used to format the time portion of date/time values. | ||
|
@@ -743,6 +769,18 @@ The function `:time` has these _options_: | |
- `medium` | ||
- `short` (default) | ||
|
||
If the _operand_ of the _expression_ is an implementation-defined date/time type, | ||
it can include other option values. | ||
Any _operand_ option values matching the `:datetime` _style options_ or _field options_ are ignored, | ||
as is any `style` option. | ||
|
||
#### Composition | ||
|
||
When an _operand_ or an _option_ value uses a _variable_ annotated, | ||
directly or indirectly, by a `:time` _annotation_, | ||
its _resolved value_ is implementation-defined. | ||
An implementation MAY emit a _Bad Operand_ or _Bad Option_ error (as appropriate) | ||
when this happens. | ||
|
||
### Date and Time Operands | ||
|
||
|
@@ -792,5 +830,3 @@ For more information, see [Working with Timezones](https://w3c.github.io/timezon | |
> The form of these serializations is known and is a de facto standard. | ||
> Support for these extensions is expected to be required in the post-tech preview. | ||
> See: https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should say
MUST
here, or at leastSHOULD
, and be specific about which options are required to be present (all of them?). The purpose here is be to allow custom function authors to extend MF2 and be able to rely on the implementations exposing these options.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can
MUST
orSHOULD
that implementation-defined date/time types contain options. The text here needs to be implementer focused:I use
MAY
here becauseSHOULD
means that every implementation must do so unless they have a good reason not to. It will be difficult to test.