Expose datetime formatting user preferences

[tc39]

Expose datetime formatting user preferences

[caridy]

The specification references to DefaultLocale() abstract operation http://tc39.github.io/ecma402/#sec-defaultlocale, but that is not exposed today. We can probably start by doing so, and expand on other default values (coming from the host environment).

[ehsan]

My proposal in #38 (comment) was for integrating this into HTML. I don't think WebIDL is used in ecma402, so we need someone else make a proposal here (but I still don't understand why we don't do this in HTML.)

[zbraniecki]

I also don't understand why this can't be part of HTML spec, especially that Intl doesn't have any event handling code.

[zbraniecki]

There's another setting that we need - timechange. We use it in Firefox OS as moztimechange for now and it is fired when either time or timezone is manually changed.

I wouldn't mind separating those two but they seem very similar to hour12 setting, timeformatchange and languagechange.

[littledan]

This bug has been reported to Chrome multiple times, e.g., https://code.google.com/p/chromium/issues/detail?id=360156 . Users seem to expect that their system preferences will be automatically propagated to methods like .toLocaleDateString() without having to propagate individual options through navigator to the method explicitly.

It seems to me like we could let the surrounding embedding context supply the meaning of 'undefined', rather than making it always provided by the locale, if 'undefined' is given for the locale. Or maybe we could have an Intl.DateTimeFormat.defaultResolvedOptions() for a standard place for these, rather than making one-off navigator properties.

@zbraniecki I think it'd be better if Mozilla would develop these new APIs without a vendor prefix. We've found these really hard to remove in the past!

[caridy]

@littledan this issue goes beyond browsers, on the server side, it gets really tricky because the system-preferences are not useful, we have been tracking this here nodejs/Intl#14

In any case, we will move forward with the initial plan from last meeting, providing access to the settings, and the first step.

[zbraniecki]

@littledan - unfortunately, there's no easy way to expose something that we can remove later.

Our current thinking is that we will expose moztimeformatchange and navigator.mozHour12 for now and moztimechange for time/timezone changes.
I'm not a huge fan of it, I believe that we'll need some WebAPI with navigator.userPreferences or navigator.settings with event listeners and simple options like bools/enums because there are more and more user settings that should be accessible to web apps.

But I don't see any progress on any API of that kind right now :/

[srl295]

BCP47 with CLDR extensions specifies here es-US-u-hc-h12 (12 hour) / es-US-u-hc-h24 (24 hour). Perhaps that could be used as an interchange format.