PartitionDurationFormatPattern: ListFormat "type" and "style"

[anba]

The internal Intl.ListFormat is currently created without any options, which means we default to type = "conjunction" and style = "long".

The style option was discussed in #14, but I don't see the approved option (option 2 - implicit pass-through) reflected in the current spec. Was this decision reverted at some point?

UTS 35 has Unit Sequences (Mixed Units), which uses <listPattern type="unit">. Does that mean according to UTS 35, we should actually use type = "unit" for the Intl.ListFormat? Or does Intl.DurationFormat not count as a "mixed units" use case?

[sffc]

The type should be "unit" and the length should be the same as the length of the time unit display names. If this is not specified in the spec, then it should be.

[FrankYFTang]

the length should be the same as the length of the time unit display names.

what do you mean about this here?
The Intl.ListFormat has the following "style": <<"long", "short", "narrow">> , which default to "long"
The Intl.DurationFormat currently has the following "style": <<"long", "short", "narrow", "digital">> , which default to "long" (but as I mentioned in #116 that was not the one presented in the slide while passing TC39 Stage 3 )
But then, each fields could has <<"long", "short", "narrow">> (for years, months, weeks, days), <<"long", "short", "narrow", "numeric", "2-digit">> (for hours, minutes, seconds), <<"long", "short", "narrow", "numeric" >>(for milliseconds, microseconds, nanoseconds) so how could we decide which one to use for the ListFormat?

How about the following mapping
ListFormat type
Always "unit" ?

DurationFormat style => ListFormat style
"long" => "long"
"short" => "short"
"narrow" => "narrow"
"digital" => "narrow"

The problem with this approach is if we have any of the "hours", "minutes" or "seconds" in "numeric" or "2-digit"

ListFormat "long" , "short", and "narrow" may not work properly with them. because we will have the following to be formatted by the ListFormat if we have something like

(new Intl.DurationFormat("en", {style: "long", hours: "2-digit"}).format({days: 3, hours: 2, minutes: 5})

[{type: "days", value:"3 days"}, {type: "hours", value: "02"}, {type: "literal", value: ":"}, {type: "minutes", value: "05"}]

if we use style "long" in ListFormat, it would be formatted as
'3 days, 02, :, 05'
but even if we use style "narrow" in ListFormat, it would be formatted as
'3 days 02 : 05'
which has an extra " " around ":"

The other issue we need to considered together is what should formatToParts output for this if we decide to change the algorithm to let the ListFormat see the input as
[{type: "days", value:"3 days"}, {type: "???", value: "02:05"}]
which could produce
'3 days 02:05'
but then what should formatToParts should produce for that?

[sffc]

How about the following mapping

DurationFormat style => ListFormat style
"long" => "long"
"short" => "short"
"narrow" => "narrow"
"digital" => "narrow"

ListFormat type
Always "unit" ?

LGTM

[FrankYFTang]

@sffc sorry, I hit my "Comment" before I complete my typing and I have to revise it. Please see the other issues I mentioned above.

[FrankYFTang]

I think we should discuss the type and style of using ListFormat separately because deciding type to use "unit" is a much simpler discussion than "style" which require a lot to resolve complexity issue with the total 11 different styles framework in DurationFormat

[anba]

if we use style "long" in ListFormat, it would be formatted as '3 days, 02, :, 05' but even if we use style "narrow" in ListFormat, it would be formatted as '3 days 02 : 05' which has an extra " " around ":"

This spacing around individual elements is locale-specific, for example "de" always prepends "und" (German for "and") before the last element.

[anba]

I think the mapping proposed above should result in the expected results. How to properly format the digital parts should be handled through #114 (and #55 for the formatToParts output).

[sffc]

'3 days, 02, :, 05'

This is not an output that should ever be generated. Fields with the "numeric" style should go through an entirely different code path, and interpolated as a single unit into the list at the end. It should be "3 days, 02:05".

[FrankYFTang]

I think the mapping proposed above should result in the expected results. How to properly format the digital parts should be handled through #114 (and #55 for the formatToParts output).

but this issue is not just under style: "digital"
consider the following under the current spec text:

(new Intl.DurationFormat("en", {style: "long", hours: "numeric"}).format({days: 3, hours: 2, minutes: 5})

[FrankYFTang]

'3 days, 02, :, 05'

This is not an output that should ever be generated. Fields with the "numeric" style should go through an entirely different code path, and interpolated as a single unit into the list at the end. It should be "3 days, 02:05".

using type: "unit" it will generate

'3 days 02:05'
instead of
'3 days, 02:05' for English

[sffc]

See #64 (comment) for an open discussion on this. I suggested:

1. "hour", "minute", and "second" must be either all "numeric" or all not "numeric".
   • We could weaken this rule, but maybe it's good to start strict.
2. If "millisecond" is "numeric", then "microsecond" must also be "numeric".
3. If "microsecond" is "numeric", then "nanosecond" must also be "numeric".

[FrankYFTang]

See #64 (comment) for an open discussion on this. I suggested:

1. "hour", "minute", and "second" must be either all "numeric" or all not "numeric".

   • We could weaken this rule, but maybe it's good to start strict.

2. If "millisecond" is "numeric", then "microsecond" must also be "numeric".

3. If "microsecond" is "numeric", then "nanosecond" must also be "numeric".

that is already the case in the current spec and has nothing to do with the issue I mentioned in

(new Intl.DurationFormat("en", {style: "long", hours: "numeric"}).format({days: 3, hours: 2, minutes: 5})

because in there, hours, minutes, seconds, milliseconds, microseconds, and nanoseconds are all "numeric" already (by step 17-i-i of https://tc39.es/proposal-intl-duration-format/#sec-Intl.DurationFormat and GetDurationUnitOptions ) but days (and also years, months, weeks) are still "long".

[ryzokuken]

As you might've seen in the review I made for the PR, I don't think type: "unit" makes sense for all styles, but instead we should stick to type: "conjuction" for longer styles (eg: "1 day, 3 hours and 15 minutes") and unit for shorter styles like digital (numeric).

[sffc]

Given that we are formatting a list of units, I think we should stick with the "unit" list type, and if we think the output could be improved for longer lengths, we should discuss that with CLDR. What we shouldn't do is make an arbitrary decision to use different list types based on what we think looks nicer in English.

[ryzokuken]

What we shouldn't do is make an arbitrary decision to use different list types based on what we think looks nicer in English.

Alright, you have my convinced, I'll merge the PR then.

[romulocintra]

#119 Closes this one