Discuss
  • Test intl402/ch12/12.1/12.1.1_18.js problem

Test intl402/ch12/12.1/12.1.1_18.js problem

# Nebojša Ćirić (13 years ago)

Error message:

Option value true for property hour12 was not accepted; got undefined instead.

If you create date formatter with: var df = Intl.DateTimeFormat([], {hour12: true})

you get only day/month/year by default, no hour data. ICU will return M/d/y pattern back, and you don't have enough data about hour12 value. As soon as you request hour data you'll get some. I wonder if we should change the spec to say that hour12 field makes sense only if hour field is present?

# Norbert Lindenberg (13 years ago)

For those puzzled by the subject line: It's a reference to a test in the growing conformance test suite for the ECMAScript Internationalization API, currently available here: lindenbergsoftware.com/ecmascript/test262/tests1013.patch

For this specific test, an implementation could simply save the value of the hour12 property provided by the caller and return it through resolvedOptions(). But if the caller doesn't provide an hour12 property, the implementation is supposed to look up whether the locale of the DateTimeFormat uses 12-hour time or 24-hour time, and that indeed doesn't make much sense if the format doesn't include an hour field.

So yes, I think we can change the spec to set the [[hour12]] internal property only if the [[hour]] internal property is present after step 28 of InitializeDateTimeFormat. That's similar to how [[currency]] depends on [[style]] in InitializeNumberFormat.

A bigger problem actually is that FormatDateTime currently ignores hour12 entirely. I'll have to fix that too: If hour12 is true, the algorithm should set hour = hour % 12, allow locales to display hour 0 as 12, and insert a localized am/pm indicator.

Any objections to these changes?

Norbert

# Phillips, Addison (13 years ago)

So yes, I think we can change the spec to set the [[hour12]] internal property only if the [[hour]] internal property is present after step 28 of InitializeDateTimeFormat. That's similar to how [[currency]] depends on [[style]] in InitializeNumberFormat.

Looking at the steps involved, you haven't taken account of the time zone offset when you pass step 28, so you can't omit setting the hour internal property, even if you're not going to display the hour field in the resulting format. That is, "2012-08-15T22:00:00Z" wants to display as "August 16, 2012" with a time zone of "Asia/Tokyo". Or did I miss something?

Addison

# Norbert Lindenberg (13 years ago)

InitializeDateTimeFormat only determines which date time components will be shown how in formatted strings. The actual conversion from a date (a number of milliseconds from January 1, 1970, midnight UTC) to corresponding year/month/day/hour/minute/second values is done by the ToLocalTime abstract operation, which is specified to take the time zone into consideration. The FormatDateTime abstract operation combines the output of the two to produce a final formatted string.

Norbert