Skip to content
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

Merged
merged 9 commits into from
Oct 14, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 39 additions & 3 deletions spec/registry.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Collaborator

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 least SHOULD, 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.

Copy link
Member

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 or SHOULD that implementation-defined date/time types contain options. The text here needs to be implementer focused:

Suggested change
it can include _style options_, _field options_, or other option values.
Implementations MAY permit callers to supply _style options_, _field options_, or other option values
as part of implementation-defined datetime types or values.

I use MAY here because SHOULD means that every implementation must do so unless they have a good reason not to. It will be difficult to test.

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)
Expand Down Expand Up @@ -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.
Expand All @@ -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
Copy link
Member

Choose a reason for hiding this comment

The 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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think probably there are three things:

  • options that MUST be passed (we want to list these)
  • options that MUST NOT be passed (we want to list these)
  • options that MAY be passed (implementation defined)

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.
Expand All @@ -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

Expand Down Expand Up @@ -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/


4 changes: 2 additions & 2 deletions test/tests/functions/date.json
Original file line number Diff line number Diff line change
Expand Up @@ -35,10 +35,10 @@
"src": "{|2006-01-02| :date style=long}"
},
{
"src": ".local $d = {|2006-01-02| :date style=long} {{{$d :date}}}"
"src": ".local $d = {|2006-01-02| :date style=long} {{{$d}}}"
},
{
"src": ".local $t = {|2006-01-02T15:04:06| :time} {{{$t :date}}}"
"src": ".local $d = {|2006-01-02| :datetime dateStyle=long timeStyle=long} {{{$d :date}}}"
}
]
}
4 changes: 2 additions & 2 deletions test/tests/functions/time.json
Original file line number Diff line number Diff line change
Expand Up @@ -32,10 +32,10 @@
"src": "{|2006-01-02T15:04:06| :time style=medium}"
},
{
"src": ".local $t = {|2006-01-02T15:04:06| :time style=medium} {{{$t :time}}}"
"src": ".local $t = {|2006-01-02T15:04:06| :time style=medium} {{{$t}}}"
},
{
"src": ".local $d = {|2006-01-02T15:04:06| :date} {{{$d :time}}}"
"src": ".local $t = {|2006-01-02T15:04:06| :datetime dateStyle=long timeStyle=long} {{{$t :time}}}"
}
]
}