Expose datetime formatting user preferences

[zbraniecki]

Cloned from whatwg/html#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 #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.

[Sharparam]

9 years later (soon a decade), what's the status on all this?

I've been down several rabbit holes beginning with "Why is the 1Password app not respecting the user regional settings?".

And after much digging, I finally arrive here. 1Password uses Electron which won't fix their formatting and blames Chromium, Chromium says they're following ECMA spec (as the above linked Chromium issue mentions).

Firefox seemingly ignores the spec and do their own (correct) thing and respects LC_TIME.

[sffc]

As far as work in TC39-TG2 is concerned, the current status is that advancement in this area is currently stalled due to challenges resolving mitigation of fingerprinting surfaces which diminish user privacy. For example, if a user in "en-US" chooses to use 24-hour time, this information can be used for ad targeting and by bad actors such as data brokers.

You can read the current proposal here: https://github.com/ben-allen/locale-extensions

And Mozilla's position here: mozilla/standards-positions#844

Firefox seemingly ignores the spec and do their own (correct) thing and respects LC_TIME.

This would surprise me given that Mozilla has been the most adamantly opposed to advancing this proposal.

[Sharparam]

That's unfortunate :( At least it sounds like it's stalled for a decent cause.

This would surprise me given that Mozilla has been the most adamantly opposed to advancing this proposal.

Maybe they are just "overriding" implementations of Date.toLocaleString and similar in ways that don't expose the actual locale then? I'm not really sure how their implementation works, but it gives the correct result in regards to system settings for date formatting, even without the option enabled that forces Firefox to look at the OS region settings.

Edit: Actually, on Windows, Firefox has the same buggy behaviour as Chrom(e|ium) does. So it's only behaving correctly on Linux systems (and maybe macOS, I'm unable to test that).

[zbraniecki]

Mozilla does separate how we expose locales to System JS context (one used for browser UI) from Web Content JS context.

I documented it here - https://firefox-source-docs.mozilla.org/intl/locale.html#web-exposed-locales
and the code can be traced from here - https://searchfox.org/mozilla-central/source/intl/locale/LocaleService.cpp#530

We do some nuanced tuning like picking the right region if the language matches between env and browser (so, your en-US browser can have en-GB regional prefs if your OS is en-GB), without compromising your privacy.

[Sharparam]

We do some nuanced tuning like picking the right region if the language matches between env and browser (so, your en-US browser can have en-GB regional prefs if your OS is en-GB), without compromising your privacy.

Ah, I remember reading about this elsewhere too and it probably explains why it works on Linux specifically for me. My main locale is en-GB and I use a custom en-SE locale for LC_TIME so I guess Firefox is able to pick that up due to both using English as the language. While on Windows, the main language and region is en-GB while the date formatting is manually overridden, and I guess Firefox doesn't pick that up because it's not tied to a locale code like it is on Linux.

Holding out hope that some kind of resolution is reached in regards to fingerprinting though, because users not seeing their preferred formatting on sites that try their best to follow best practices is frustrating (such sites would be required to allow the user to override formatting and save it in user settings, cookies, local storage, or something like it).