Read-only OS time formatting preferences

[zbraniecki]

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.

[zbraniecki]

There a several similar preferences that the API should either expose now, or be able to add in the future - timezone selection manual/automatic, showing/hiding dayperiod (am/pm) for 12h clock, showing/hiding seconds etc.

[ehsan]

I propose the following API:

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

Also, applications which want to customize the time display according to the OS defaults, and they need to be notified when the OS defaults change in order to have a chance to update their UI. Therefore, I think we need to queue a task to fire a simple event named systemhour12change event at the Window or WorkerGlobalScope object, similar to the languagechange event, and only return the updated value from systemHour12 when the task begins to execute.

[zbraniecki]

@ehsan - If we decide to add another time formatting setting API like this in the future (let's say, ampm display), will we want navigator.dayperiodStyle and a new event dayperiodstylechange on window?

I'm wondering if it would make sense to plan the API to handle more than one setting (and get one event for all time/date formatting options)?

[ehsan]

@ehsan - If we decide to add another time formatting setting API like this in the future (let's say, ampm display), will we want navigator.dayperiodStyle and a new event dayperiodstylechange on window?

What is "ampm display"? If you mean displaying AM/PM next to times, is that not the same as hour12?

I'm wondering if it would make sense to plan the API to handle more than one setting (and get one event for all time/date formatting options)?

I usually prefer specific solutions to specific problems. I don't think we should try to create anything generic here, all we're talking about is a boolean flag. :)

[annevk]

What is the benefit of the "system" prefix? Also, if we return "boolean" we cannot return "undefined", which appears to be necessary per the referenced bug. I think we'll need to use "any" or maybe "(boolean or undefined)" but I don't think that's allowed. @heycam?

[zbraniecki]

What is "ampm display"? If you mean displaying AM/PM next to times, is that not the same as hour12?

No. hour12 is specifying which hour formatting user wants - 12h or 24h. If the user decides to use 12h, he can further choose to display am/pm token or not.

See MacOS settings screenshot for an example: http://imgur.com/FxosgeL

It means that the same time (14:23) can be formatted as:

• 14:23 (hour12: false)
• 2:23 PM (hour12: true, dayperiod: true)
• 2:23 (hour12: true, dayperiod: false)

So, my thought is that there seem to be a set of options that user specifies in his settings app that should be exposed, read-only, to the web developer. Examples (from macos):

• First day of the week (Mon-Sun)
• Calendar (Gregorian, Buddhist, Persian, Japanese, Islamic etc.)
• Show AM/PM

I don't see a need to specify that now, but if we standardize it, I'd be worried about specifying each one of them separately on navigator until we get to the point where we need a new API to collect them and deprecate the previous ones. But you guys have way more experience so I trust you when you say that a property on navigator is a good choice. It's definitely easy for us since that's what we use right now in FxOS :)

[annevk]

We wouldn't add a new API just to collect stuff from elsewhere.

[zbraniecki]

ok, sounds good!

[domenic]

This seems out of scope for HTML. It is rather part of the ES internationalization API, I would think.

Otherwise, I'd expect HTML to grow a huge family of APIs for exposing current system locale settings.

[domenic]

E.g. in .NET their equivalent of the internationalization API contains a CultureInfo.CurrentCulture static value which contains all the locale settings currently present. You then pass these CultureInfo objects to various formatting methods (DateTimeOffset.ToString, etc.).

I really think only the ES internationalization working group will have the expertise to develop the correct system here.

[annevk]

@domenic the ES Internationalization API doesn't expose system settings. navigator, however, does. E.g., language, languages, OS, online, do not track.

[domenic]

Sure. But I think the ES API should. It's useful in more than just the browser.

Alternately, the 402 group could work on a separate spec extending navigator.

Either way, out of scope for HTML.

[ehsan]

What is the benefit of the "system" prefix?

It makes the name different to hour12 which is used in the Internationalization API (but I don't feel strongly about the name.)

Also, if we return "boolean" we cannot return "undefined", which appears to be necessary per the referenced bug. I think we'll need to use "any" or maybe "(boolean or undefined)" but I don't think that's allowed.

That is true. We can also return an enum with three values if the above is not an option.

[zbraniecki]

@caridy - what do you think? Should we take this into Ecma 402?

I feel like there are three ways we can slice it: 1) It's a standalone variable that should be available to the web developer 2) It's part of the Intl Time/Format data and as such should be part of Ecma 402 3) It's part of the "User preferences" data and as such should be part of HTML/DOM.

[ehsan]

@domenic How would an ES level solution notify the application when the system settings change?

[caridy]

yes, we can take part of this into 402, open the issues in the ecma 402 repo.

[zbraniecki]

@caridy - do you have an answer to the event question @ehsan ? I'm not sure if it should be 402 or here.

[annevk]

@domenic I really don't see why this would be out of scope, but navigator.languages (and corresponding event) is not.

[heycam]

Also, if we return "boolean" we cannot return "undefined", which appears to be necessary per the referenced bug. I think we'll need to use "any" or maybe "(boolean or undefined)" but I don't think that's allowed. @heycam?

Right, the only way currently to do that is to use "any". (It's on my todo list to add an "undefined" IDL type to make this easier.)

[domenic]

@annevk Let me clarify a bit. This isn't necessarily out of scope, in that HTML is the kitchen sink and we can justifiably say that anything is in its scope.

However, the OP and the couple of posts following it make it clear that this is a pretty large new undertaking, which ideally integrates deeply with the work done in 402, e.g. allowing passing of this "culture info" or "locale data" object to 402's toLocale{String,DateString,TimeString,LowerCase,UpperCase} overloads or to its Intl.{Collator,DateTimeFormat,NumberFormat} constructors. It would need to integrate with 402's existing notion of locale data, for example. And it would need to tease out the relationship between intrinsic locale data, derived directly from a language tag, and user preferences. (Possibly the former sets defaults that can be overridden by the latter? Possibly user preferences create a new locale, that doesn't have a language tag? Not my area of expertise, but I am sure these problems have been solved before...)

Thus, I think an undertaking like this should ideally be developed in tandem with those 402 APIs for best integration, and maintained by a group that has good familiarity with those APIs and can work alongside those editors (or maybe that group should just be the 402 editors). Making it the responsibility of the HTML editors seems like a bad idea, especially since it doesn't gain anything compared to a separate spec. There are no deep hooks into the HTML spec needed; this would be a fine extension spec. Maybe even navigator.languages can be moved there, or subsumed into the new model.

[caridy]

as for events, this is tricky for fee reasons:

1. intl instances are normally very expensive to create (compared with pure js objects), which makes using cache layers in user land a very common practice,adding events to that equation adds a lot of complexity.
2. there is no precedent for such thing in 262 or 402 that I lnow about.
3. this is a very edge case (most users will never change those settings, and they certainly will not expect the page to readjust automatically).
4. universal/isomorphic apps will have a hard time producing initisl payload on the server if there are settings that are very specific to the client runtime. Today it is all about selecting the locale in which your app will run as part of the negotiation process, but going beyong that will make tools like react to complain about checksum errors since the content produced by the server will not match the same content produced by the client with the exact same data. the only way to solve this is to send these settings to the server side as par of the request headers, and that seems weird to me.

[ehsan]

However, the OP and the couple of posts following it make it clear that this is a pretty large new undertaking.

It really isn't. I am quite puzzled by why you think that.

[domenic]

It really isn't. I am quite puzzled by why you think that.

Here is what the equivalent work looked like for .NET:

• CultureInfo
• TextInfo
• DateTimeFormatInfo
• NumberFormatInfo

I appreciate the OP contained only an incomplete version of DateTimeFormatInfo, i.e. hour12. But then in the second post onward it started expanding to dayperiodstyle---which already mismatches 402, so we're having a group coordination problem here. Other 402 options that might change due to user settings include timeZone and the various formatting parameters, or even the calendar. hourNo0 also is treated as similar to hour12 in 402, so I am not sure why hour12 is included but hourNo0 is not.

If this is going to be an incompletely-done solution, I don't want it in HTML; we should have higher standards for this spec. If it's going to be a completely done solution with good 402 integration, then I think it needs domain expertise outside of what HTML offers. The speed to which people have jumped to nitty-gritty IDL details, and your incomprehension of how large this problem space is, are worrying...

[domenic]

As an idea to get things started, something that integrates better with 402 might be something like Intl.DateTimeFormat.current or navigator.currentDateTimeFormat that reflects the user's current choices of date-time formatting. You'd then use Intl.DateTimeFormat's equivalent for AM/PM style instead of inventing dayperiodstyle.

[zbraniecki]

I don't fully understand what would be Intl.DateTimeFormat.current, but if it's a collection of user preferences then it should not belong to Intl.DateTimeFormat. We'd need sth like Intl.EnvironmentSettings, which is ok except that Intl doesn't have any prior experience with event handling and we rely on HTML's navigator.languagechange to reformat when languages change.

I would expect similar navigator.timeformatchange rather than adding EventHandler to Intl.

Does it make sense?

Wrt. scope. Currently all we need is a single true/false/undefined variable. I wanted to plan it ahead for additional data, but @ehsan suggested to focus on the task at hand which I agree with. So I see it as a single variable and a single event when the variable changes. HTML seems better suited IMO.

[domenic]

I don't fully understand what would be Intl.DateTimeFormat.current

Because Intl.DateTimeFormat instances are what you use to format datetimes, you should have one representing the user's current preferences for how to format datetimes.

You can use navigator as a storage place, without using HTML as a spec.

[annevk]

@domenic are the maintainers of 402 interested in extending navigator? I'm happy to add a couple of properties and events as needed over time to HTML. Not a big deal. I don't really want to say out-of-scope when the alternative can take a long time.

[caridy]

@annevk no, we are not interested on navigator, we only care about the abstract operations to access the default intl values (locales, etc), and potentially expose them to the runtime. One common practice today is that developers will create an instance of Intl.NumberFormat() just to access locale from the resolvedOptions of the instance. We want to provide low level APIs to do the same without having to create an instance.

Aside from that, settings like hour12 are inferred via locales, changing that to use a system setting will imply that the server side can't negotiate all those settings. I'm concern about the navigator's specific properties that can affect the way Intl works because we don't have navigators in all runtimes (e.g.: node), and also the fact that universal/isomorphic code will not produce the same results since we don't have the ability to pick all the user's settings from a request.

[domenic]

@annevk I really do not like the framing of this as "a couple of properties and events". It should integrate better with 402's primitives, e.g. as in https://github.com/whatwg/html/issues/171#issuecomment-142334573.

Even if the 402 group is not interested in extending navigator, I'd expect their help and sign-off on any design of this sort.

[annevk]

@zbraniecki is this still something you want to pursue in the HTML Standard?

[caridy]

I think we have come to "agreement" on the idea of using navigator.locales (which is BC) and can contains locales with extensions, while all 402 primitives can digest extensions just fine.

[annevk]

Thanks, what does BC mean?

[caridy]

backward-compatible since it is a new member of navigator.

[annevk]

I see, so should we introduce these members in the HTML Standard or will something else introduce an extension of sorts? Anyone willing to provide a PR?