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:
http://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
On Aug 15, 2012, at 17:50 , Nebojša Ćirić wrote:
> 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?
>
> --
> Nebojša Ćirić
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
