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
Fix incorrect expectation of resolvedOptions.locale while no "hour" in options #2035
Conversation
Notice the comment stated: // Also test the case when no hour option is present at all. // The resolved options don't include hour12 and hourCycle if the date-time // formatter doesn't include an hour option. This restriction doesn't apply // to the hc Unicode extension value. If so, for that test without hour:, it should equal to locale, not expectedLocale
No, the test is correct as is. The comment tries to explain that even though the resolved options don't contain InitializeDateTimeFormat, step 29 only sets [[HourCycle]] when [[Hour]] is not undefined, otherwise (step 30) [[HourCycle]] is set to undefined, too. That means for Intl.DateTimeFormat.prototype.resolvedOptions, the resolved options only contain The resolved locale however is computed before we know whether or not [[Hour]] is present in the date-time formatter, cf. InitializeDateTimeFormat, step 11. So the |
OK, following your logic- could you show me what should the following 8 cases output? A (new Intl.DateTimeFormat("en-u-hc-h11", { hour12: false, hourCycle: "h23"}).resolvedOptions()).locale |
@anba Could you just show me what do you think the above 8 cases should output, one by one? |
I agree with your statement quoted above, and that is exactly why the tests was wrong and need this PR. The test is currently assert the resolvedOptoins.locale is the same as "expectedLocale" (the 2nd) argument, which if you read the caller's code, are "defaultLocale" for all except one case. And defaultLocale is the one WITHOUT |
"en".
"en".
"en".
"en-u-hc-h11".
"en".
Same as E.
"en".
"en"
|
So the test is still correct. |
Basically an |
@anba thank you so much. This part of the spec is very tricky to figure. I think the comment below really confuse me // Also test the case when no hour option is present at all. Maybe we need to change the comment to make it clear? But I now agree w/ you this test is according to the spec. Sorry for bothering yo about this. |
No worries. The ResolveLocale operation is definitely a bit tricky, I think I only started to understand it completely after I had implemented it from scratch. 😄 |
Notice the comment stated:
// Also test the case when no hour option is present at all.
// The resolved options don't include hour12 and hourCycle if the date-time
// formatter doesn't include an hour option. This restriction doesn't apply
// to the hc Unicode extension value.
If so, for that test without hour: in options, the resolved locale should equal to locale, not expectedLocale
@littledan @anba @Ms2ger