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.

Sign up for GitHub

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

Jump to bottom

Define function composition for date/time values #814

Merged
merged 9 commits into from
Oct 14, 2024
Merged

Define function composition for date/time values #814

Changes from 4 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
ca22a2c
Define function composition for date/time values
eemeli Jul 1, 2024
30d022b
Apply suggestions from code review
eemeli Jul 8, 2024
0cc8eef
Drop the "only"
eemeli Jul 15, 2024
dc776e1
Update spec/registry.md
eemeli Jul 15, 2024
2242035
Update spec/registry.md
aphillips Oct 7, 2024
3d335fe
Update spec/registry.md
aphillips Oct 7, 2024
05040e3
Update spec/registry.md
aphillips Oct 7, 2024
93d0794
Merge branch 'main' into datetime-composition
eemeli Oct 10, 2024
54fa33e
Make :date and :time composition implementation-defined
eemeli Oct 10, 2024
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
45 changes: 42 additions & 3 deletions spec/registry.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -796,6 +796,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 @@ -897,7 +902,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
aphillips marked this conversation as resolved.
Show resolved Hide resolved
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 @@ -921,6 +934,19 @@ The function `:date` 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.
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 contains the implementation-defined date/time value
aphillips marked this conversation as resolved.
Show resolved Hide resolved
of the _operand_ of the annotated _expression_ (with no time value),
eemeli marked this conversation as resolved.
Show resolved Hide resolved
together with the resolved options values.

### The `:time` function

The function `:time` is used to format the time portion of date/time values.
Expand All @@ -944,6 +970,21 @@ 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 contains the implementation-defined date/time value
aphillips marked this conversation as resolved.
Show resolved Hide resolved
of the _operand_ of the annotated _expression_ (with no date value),
eemeli marked this conversation as resolved.
Show resolved Hide resolved
together with the resolved options values.

Using a `:time` annotated value as the _operand_ of `:datetime` or `:date`
produces a _Bad Operand_ error as it contains no date value.
eemeli marked this conversation as resolved.
Show resolved Hide resolved

### Date and Time Operands

Expand Down Expand Up @@ -993,5 +1034,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/