-
Notifications
You must be signed in to change notification settings - Fork 149
-
Notifications
You must be signed in to change notification settings - Fork 149
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
Clarify timeStyle:long/full for Plain types #2795
Comments
This is a shortcoming in the reference code, I think. Time zone should never be printed for Plain types. But I can't remember off the top of my head if the spec says to throw in that case, or to ignore the |
I looked at the spec and I believe it should be ignored. In step 57 of CreateDateTimeFormat we consult Table 27 to see which options are supported for each Temporal type, and only copy supported options from formatOptions to limitedOptions for use in determining the DTF pattern for that Temporal type. |
Thanks for the info @ptomato. The algorithm you describe for copying DateTimeFormat options makes sense. The problem I'm posing is actually not very related to The crux of the problem is related to Temporal.Now.plainDateTimeISO().toLocaleString('en', {
timeStyle: 'full',
})
// "3:14:26 PM Eastern Standard Time" for me This is a shortcoming with the reference implementation specifically. The |
Yes, please feel free! The reference polyfill already uses plenty of other workarounds in |
Got it, thanks @ptomato. Then I assume this is a mistake in this test: The That test is currently being ignored but I can make a fix so that when it comes back online it won't cause problems. |
It's not obvious to me that there's a desired behaviour that will meet everyone's expectations all the time. But reading the spec I agree that |
I've created #2904 to sync the Temporal.Now.plainDateTimeISO().toLocaleString("en", {
timeStyle: "full",
}) the same time format is used for all types ( Without #2904, this step is relevant:
When the current type is With #2904, the time format selection should be more easy to understand when That being said, I'm not sure the current spec matches previous consensus. For example the current spec requires that this throw a new Intl.DateTimeFormat("en", {dateStyle: "long"}).format(new Temporal.PlainTime()); whereas this call succeeds and returns the string new Intl.DateTimeFormat("en", {day: "numeric"}).format(new Temporal.PlainTime()); |
Meeting, 2024-09-19: We believe this is probably just a bug in the JS code and that the spec text is correct, but that needs to be verified. The principle is that Intl.DateTimeFormat resolves options for all fields, but if you format a limited type like PlainYearMonth, you only use the options for year and month. Just to make sure we are all talking about the same thing, I made a table of expected results (in my locale and time zone) for formatting the various limited Temporal types with various DateTimeFormat options. Let me know if you disagree with anything in this table.
Note that the time zone name is printed when formatting Instant with a timeStyle that includes the time zone. This is intentional, even though Instant does not include a time zone, it is the Temporal analogue to legacy Date and behaves the same way in formatting. If there are no objections to this table, I'll verify that this is actually what the implementation-defined parts of the spec text suggest, and that it is covered by test262 tests. |
Hello!
All the Plain* types accept timeZoneName/timeZone for their
toLocaleString
string methods but they're ignored:However, when
timeStyle
is set to either'full'
or'long'
, the time zone is included:I this intentional? Or just a shortcoming of the reference polyfill?
If it is in fact a shortcoming, and the reference polyfill should not be doing this, I would recommend internally forcing
timeStyle
'full'
or'long'
to'medium'
to omit the timeZone.I've tested to see whether the 'medium' is always simply the 'long' or 'full' minus the timezone, and it seems to be the case:
https://codepen.io/arshaw/pen/MWRYKqV?editors=0010
This technique doesn't work for Dzongkha/Esperanto in Firefox/Safari, but still probably okay to force it 'medium' for those locales nonetheless.
I'm happy to create a PR for this if applicable.
The text was updated successfully, but these errors were encountered: