Expose datetime formatting user preferences

[zbraniecki]

Cloned from https://github.com/whatwg/html/issues/171

All operating systems allow user to select time format. Usually between 12h, 24h or follow automatic.

Firefox OS is currently providing navigator.mozHour12 that can take true/false/undefined values and that nicely fits into Intl API:

(new Date()).toLocaleString(navigator.languages, {
  hour12: navigator.mozHour12,
  hour: 'numeric',
  minute: 'numeric'
});

When "use default" is used, mozHour is undefined and Intl uses the default hour12 value for the given locale. If mozHour is specified to either true or false, Intl API follows that.

There's also an event associated with it: timeformatchange that is dipatched on window.

We're not yet sure if it should be part of Ecma 402 or HTML spec because of events, but I'm opening the issue here to start the conversation in case the HTML group will throw it here.

I can see us wanting to design the API to handle more than one preference or just follow @ehsan's proposal from the HTML issue:

[NoInterfaceObject, Exposed=(Window,Worker)]
interface NavigatorSystemHour12 {
  readonly attribute boolean systemHour12;
};
Navigator implements NavigatorSystemHour12;
WorkerNavigator implements NavigatorSystemHour12;

[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 https://github.com/tc39/ecma402/issues/38#issue-107613659 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 https://github.com/nodejs/Intl/issues/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.