{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/ecma402/issues/108","repository_url":"https://api.github.com/repos/tc39/ecma402","labels_url":"https://api.github.com/repos/tc39/ecma402/issues/108/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecma402/issues/108/comments","events_url":"https://api.github.com/repos/tc39/ecma402/issues/108/events","html_url":"https://github.com/tc39/ecma402/issues/108","id":183158971,"number":108,"title":"short/medium/long/full style for Intl.DateTimeFormat","user":{"login":"zbraniecki","id":449986,"avatar_url":"https://avatars.githubusercontent.com/u/449986?v=3","gravatar_id":"","url":"https://api.github.com/users/zbraniecki","html_url":"https://github.com/zbraniecki","followers_url":"https://api.github.com/users/zbraniecki/followers","following_url":"https://api.github.com/users/zbraniecki/following{/other_user}","gists_url":"https://api.github.com/users/zbraniecki/gists{/gist_id}","starred_url":"https://api.github.com/users/zbraniecki/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zbraniecki/subscriptions","organizations_url":"https://api.github.com/users/zbraniecki/orgs","repos_url":"https://api.github.com/users/zbraniecki/repos","events_url":"https://api.github.com/users/zbraniecki/events{/privacy}","received_events_url":"https://api.github.com/users/zbraniecki/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":35,"created_at":"2016-10-14T21:56:18Z","updated_at":"2017-02-15T18:17:25Z","closed_at":null,"body":"I'm working on trying to design an alignment between how Intl API works and OS Intl preferences work.\n\nAn example of such task is how to incorporate the date/time formatting OS user preferences into DateTimeFormat API.\n\nCurrently, we expect users of our API to list the elements of the date/time format as options, or, if none are listed, we take:\n- for `Intl.DateTimeFormat` and `Date.prototype.toLocaleString`: hour/minute/second/day/month/year as `numeric`\n- for `Date.prototype.toLocaleTimeString`: hour/minute/second as `numeric`\n- for `Date.prototype.toLocaleDateString`: day/month/year as `numeric`\n\nOn the other hand, MacOS exposes four styles for date and time: short, medium, long and full.\nWindows exposes short/long.\n\nI see two solutions to bind those two APIs:\n\n1) Create OS Intl prefs API that returns Intl API options.\n\n``` javascript\nlet opts = intlOSPrefs.DateFormat(intlOSPrefs.formatFull);\n  --> returns {weekday: 'long', month: 'long', day: 'numeric', year: 'numeric'}\nlet dtf = new Intl.DateTimeFormat(navigator.locales, opts);\ndtf.format(date);\n```\n\n2) Add `style` option and change how we handle \"defaults\" in Intl.DateTimeFormat\n\nIn this approach, we would use the language in spec similar to one we use for timezones: if user did not specify a timezone, we try to retrieve it from the host OS and we land on the current defaults (all as `numeric`) only if we cannot get anything from the OS.\n\n``` javascript\ndate.toLocaleString() == date.toLocaleString(navigator.locales, {\n  style: 'medium'\n}) == date.toLocaleString(navigator.locales, {\n  day: 'numeric',\n  month: 'short',\n  year: 'numeric'\n}); // In MacOS\n\ndate.toLocaleDateString(navigator.locales, {\n  style: 'long'\n}) == date.toLocaleString(navigator.locales, {\n  day: 'numeric',\n  month: 'long',\n  year: 'numeric'\n}); // default in MacOS\n\n\ndate.toLocaleDateString(navigator.locales, {\n  style: 'full'\n}) == date.toLocaleString(navigator.locales, {\n  weekday: 'long',\n  day: 'numeric',\n  month: 'long',\n  year: 'numeric'\n}); // default in MacOS\n```\n\nThat would require adding an additional step in `12.1.2 ToDateTimeOptions` as `6.a` and `7.a` where the implementation could reach to host OS for the preferences and only fallback to the current `6.a` and `7.a` if those cannot be retrieved.\n\nIn this approach, `style` option would be mutually exclusive with any of the token options.\n\nOpinions? @caridy , @rxaviers , @jungshik, @srl295 ?\n"},"comment":{"url":"https://api.github.com/repos/tc39/ecma402/issues/comments/280092771","html_url":"https://github.com/tc39/ecma402/issues/108#issuecomment-280092771","issue_url":"https://api.github.com/repos/tc39/ecma402/issues/108","id":280092771,"user":{"login":"zbraniecki","id":449986,"avatar_url":"https://avatars.githubusercontent.com/u/449986?v=3","gravatar_id":"","url":"https://api.github.com/users/zbraniecki","html_url":"https://github.com/zbraniecki","followers_url":"https://api.github.com/users/zbraniecki/followers","following_url":"https://api.github.com/users/zbraniecki/following{/other_user}","gists_url":"https://api.github.com/users/zbraniecki/gists{/gist_id}","starred_url":"https://api.github.com/users/zbraniecki/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zbraniecki/subscriptions","organizations_url":"https://api.github.com/users/zbraniecki/orgs","repos_url":"https://api.github.com/users/zbraniecki/repos","events_url":"https://api.github.com/users/zbraniecki/events{/privacy}","received_events_url":"https://api.github.com/users/zbraniecki/received_events","type":"User","site_admin":false},"created_at":"2017-02-15T18:17:25Z","updated_at":"2017-02-15T18:17:25Z","body":"@rxaviers - as @jfkthame said, I believe that skeleton is not very different from current verbose options. pattern is not only what OS gives us. It also contains more information (including any arbitrary literals).\r\n\r\n@NorbertLindenberg \r\n> One problem I have with style names \"full\", \"long\", \"medium\", \"short\" is that they don't tell me what information is actually going to be provided to the user.\r\n\r\nI believe it to be on purpose. If you ask for a \"short time format\" you hand over control over what bits exactly will be displayed to the API that will chose the best string that will represent this data.\r\nWhat's more, it may actually differ between locales, and I also believe it to be a good thing.\r\n\r\nThe way I think about the API extension I'm proposing is that if you want to control what bits you return, that means you want to use verbose options. If you just want the short time, you use style.\r\n\r\nWhen working with developers who will use the API at Mozilla, they don't want to have to decide each time between `YMD-medium` and `WYMD-medium`. They just want to display date, and they can tell us that they have `medium` amount of space for that in the UI.\r\n\r\nOn top of that experience, I believe it's worth looking at what OSes and ICU are doing because a) their UX teams put effort into figuring out the right balance between flexibility and user experience, and b) this is the level of granularity that OS UX speaks, so it makes any bindings easier.\r\n\r\nTo sum it up:\r\n\r\n* skeleton is just a compressed way to write the current options\r\n* Norbert's proposal is another level of granularity between style and skeleton.\r\n\r\nIn my opinion `timeStyle`, `dateStyle` are the most valuable next steps. `pattern` is just convenient and easy to add option that allows any user-level libraries to design their own patterns and use `Intl.DateTimeFormat` to format it (including formatToParts).\r\nFor those reasons, I'd like to focus on those two now, but I'll refer to the editor for decision. @caridy ?"}}
{"actor":{"display_login":"zbraniecki"}}