Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose datetime formatting user preferences #38

Open
zbraniecki opened this issue Sep 21, 2015 · 8 comments
Open

Expose datetime formatting user preferences #38

zbraniecki opened this issue Sep 21, 2015 · 8 comments
Labels
c: meta Component: intl-wide issues s: discuss Status: TG2 must discuss to move forward User Preferences Related to user preferences

Comments

@zbraniecki
Copy link
Member

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
Copy link
Contributor

caridy commented Sep 22, 2015

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
Copy link

ehsan commented Sep 22, 2015

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Contributor

caridy commented Dec 15, 2015

@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
Copy link
Member Author

@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
Copy link
Member

srl295 commented Dec 15, 2015

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.

@caridy caridy added this to the 4rd Edition milestone Feb 29, 2016
@sffc sffc added s: discuss Status: TG2 must discuss to move forward c: meta Component: intl-wide issues and removed enhancement labels Mar 19, 2019
@sffc sffc added s: comment Status: more info is needed to move forward and removed s: discuss Status: TG2 must discuss to move forward labels Apr 23, 2020
@sffc sffc added the User Preferences Related to user preferences label Jun 5, 2020
@sffc sffc removed this from the 4th Edition milestone Jun 5, 2020
@sffc sffc added s: discuss Status: TG2 must discuss to move forward and removed s: comment Status: more info is needed to move forward labels Jun 5, 2020
@sffc sffc moved this to Previously Discussed in ECMA-402 Meeting Topics Aug 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: meta Component: intl-wide issues s: discuss Status: TG2 must discuss to move forward User Preferences Related to user preferences
Projects
Archived in project
Development

No branches or pull requests

6 participants