Should list format for "digital" also switch from "narrow" to "short"

[FrankYFTang]

In https://github.com/tc39/proposal-intl-duration-format/issues/85 TG2 decided to switch the "Digital Default" for years, months, weeks and days from "narrow" to "short"

Currently, in https://tc39.es/proposal-intl-duration-format/#sec-partitiondurationformatpattern we have

6. Let listStyle be durationFormat.[[Style]].
7. If listStyle is "digital", then
a. Set listStyle to "narrow".

The question is should the listStyle set by step 7-a also swap from "narrow" to "short" for "digital" or should we keep it as "narrow" ?

@sffc @ryzokuken @ptomato

[ryzokuken]

I believe this is not a good path for us. This isn't something that makes much of a difference implementation-wise, and is purely a design decision. Besides, it's unclear how much "better" it would make the output so it's clearly just a "what if".

With all that in mind, and given that the proposal is in Stage 3, I'd strongly recommend we avoid changes like these as much as we can.

[FrankYFTang]

I am not stronlgy suggest us to change it. It is just this is related to the https://github.com/tc39/proposal-intl-duration-format/issues/85 and I would like TG2 to clarify since the decision in https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-09-01.md#should-the-default-digital-non-numeric-style-be-short-or-narrow-85 and this logic in combination may produce unexpected output and I think we should think through about it.

Here is why I ask this question, it is not about the implementation, but the oddness of the output. If the durationFormat.[[Style]] is "digital" The only item could be formated by the list format are only up to (could be less) 5 items 1) years, 2) months, 3) weeks, 4) days, 5) the combination of hours, minutes, seconds and fractional seconds.

notice, currently the digital default is "short" , not "narrow" therefore, each of the 1) years, 2) months, 3) weeks, 4) days are formatted by the number formatter in the form of "short".

But with the current spec text which change listStyle to "narrow", it will be using the "narrow" pattern to put these 5 thing together.

Consider the following

d8> d = {years: 1, days: 5, hours: 3}
{years: 1, days: 5, hours: 3}
d8> (new Intl.DurationFormat("en")).format(d)
"1 yr, 5 days, 3 hr"
d8> (new Intl.DurationFormat("en", {style: "short"})).format(d)
"1 yr, 5 days, 3 hr"
d8> (new Intl.DurationFormat("en", {style: "narrow"})).format(d)
"1y 5d 3h"

Now, what should be the output of

d8> (new Intl.DurationFormat("en", {style: "digital"})).format(d)

If we use "narrow" for the list format style, it will be

"1 yr 5 days 3:00:00"

If we use "short" for the list format style, it will be

"1 yr, 5 days, 3:00:00"

[sffc]

We had already settled the question about ListFormat length being the same as DurationFormat unit length. Given the choice to switch Digital to short units, it should also change to short list style. The two changes should happen in tandem, at the same time, ideally in the same PR. It is a bug if they get out of sync.

[FrankYFTang]

The two changes should happen in tandem, at the same time, ideally in the same PR. It is a bug if they get out of sync.

I didn't do so in https://github.com/tc39/proposal-intl-duration-format/pull/123/ so I will fill a PR for the list style.

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-10-06.md#should-list-format-for-digital-also-switch-from-narrow-to-short-125

@Constellation and @FrankYFTang, who have started implementing Intl.DurationFormat, both agreed that this is a reasonable change to improve consistency. I am also strongly in favor and see it as a bug in the spec.

@ryzokuken, how do you feel?

[ryzokuken]

@sffc alright, I understand that the group was in consensus over this being a bug so I'll go ahead and approve it, then present it to the committee.