{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/ecma402/issues/190","repository_url":"https://api.github.com/repos/tc39/ecma402","labels_url":"https://api.github.com/repos/tc39/ecma402/issues/190/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecma402/issues/190/comments","events_url":"https://api.github.com/repos/tc39/ecma402/issues/190/events","html_url":"https://github.com/tc39/ecma402/issues/190","id":266638908,"number":190,"title":"DateTimeFormat: add support options.raw (aka pattern)","user":{"login":"jungshik","id":8578343,"avatar_url":"https://avatars1.githubusercontent.com/u/8578343?v=4","gravatar_id":"","url":"https://api.github.com/users/jungshik","html_url":"https://github.com/jungshik","followers_url":"https://api.github.com/users/jungshik/followers","following_url":"https://api.github.com/users/jungshik/following{/other_user}","gists_url":"https://api.github.com/users/jungshik/gists{/gist_id}","starred_url":"https://api.github.com/users/jungshik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jungshik/subscriptions","organizations_url":"https://api.github.com/users/jungshik/orgs","repos_url":"https://api.github.com/users/jungshik/repos","events_url":"https://api.github.com/users/jungshik/events{/privacy}","received_events_url":"https://api.github.com/users/jungshik/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2017-10-18T20:55:44Z","updated_at":"2017-10-27T22:59:57Z","closed_at":null,"author_association":"NONE","body":"This is spun off from #108 and #119.  \r\n\r\nIn #108, one argument against adding 'pattern' is that API users would be confused between 'pattern' and 'skeleton'. I learned that Globalize.js uses 'raw' to mean 'pattern'.  'raw' is much less likely to be confused with 'skeleton' than 'pattern' is. \r\n\r\nAnother argument against it is that it gives API users the freedom to do \"bad things\" (piecing components together in such a way that does not make sense or is confusing in some locales ). \r\n\r\nUse cases for 'raw'. \r\n\r\n1. Locale-agnostic date time format (month names, weekday names, tz names etc would be still localized if they're used in a requested format) such as ISO 8601 .  \r\n  \r\n2.  Formats not supported by available forms. The following attempt to retrieve the timezone display name does not work because it's expanded to include \"date\".   \r\n\r\n> var df = new Intl.DateTimeFormat(\"en\", {'timeZoneName': 'long'});\r\nundefined\r\n> df.format()\r\n\"10/18/2017, Pacific Daylight Time\"\r\n\r\nGlobalize.js supports this case with ```raw(\"<timezone format specifier in LDML>\"```.   \r\n\r\nTo emulate the timezone portion of the current output of 'Date.prototype.toString()', one would use ```raw(\"ZZZZ (zzzz)\"``` (assuming that the format is locale-agnostic, which may not be true). \r\n\r\nI realize that I didn't put up a very strong case for 'raw' ('pattern') and regard this issue as a forum for input from others. I also want to separate this issue  from #108, which gets too long with multiple issues discussed and #189 (options.skeleton). \r\n\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/tc39/ecma402/issues/comments/340116733","html_url":"https://github.com/tc39/ecma402/issues/190#issuecomment-340116733","issue_url":"https://api.github.com/repos/tc39/ecma402/issues/190","id":340116733,"user":{"login":"caridy","id":38969,"avatar_url":"https://avatars1.githubusercontent.com/u/38969?v=4","gravatar_id":"","url":"https://api.github.com/users/caridy","html_url":"https://github.com/caridy","followers_url":"https://api.github.com/users/caridy/followers","following_url":"https://api.github.com/users/caridy/following{/other_user}","gists_url":"https://api.github.com/users/caridy/gists{/gist_id}","starred_url":"https://api.github.com/users/caridy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/caridy/subscriptions","organizations_url":"https://api.github.com/users/caridy/orgs","repos_url":"https://api.github.com/users/caridy/repos","events_url":"https://api.github.com/users/caridy/events{/privacy}","received_events_url":"https://api.github.com/users/caridy/received_events","type":"User","site_admin":false},"created_at":"2017-10-27T22:59:57Z","updated_at":"2017-10-27T22:59:57Z","author_association":"COLLABORATOR","body":"In most cases, you can get away with transforming a pattern/skeleton into a DateTimeFormat options, specially if you're flexible with the output. E.g.: \r\n\r\n```js\r\nvar f = {\r\n  weekday: 'long',\r\n  month: 'long',\r\n  day: 'numeric',\r\n  year: 'numeric',\r\n  hour: 'numeric',\r\n  minute: '2-digit',\r\n  second: '2-digit',\r\n  hour12: true,\r\n  timeZoneName: 'long'\r\n};\r\nnew Intl.DateTimeFormat('en-US', f).format(Date.now())\r\n\"Friday, October 27, 2017, 4:14:53 PM Eastern Daylight Time\"\r\n```\r\n\r\nMost browsers, today, will add a comma after the year (IE11 does something slightly different) for that set of options. But if you look at the latest ICU library, we see this pattern: `\"EEEE, MMMM d, y 'at' h:mm:ss a zzzz\"`, which does have  an `at` in between and no coma for `en-US`.\r\n\r\nI wrote some experimental library to try to see if we can help people who want to use patterns/skeleton for convenience, but still preserving the invariants of `Intl` to do the right thing depending of the locale.\r\n\r\nhttps://github.com/caridy/intl-datetimeformat-pattern\r\n\r\nWith a library like this, you can get from that pattern/skeleton to the most likely option object that will produce something very similar, but in some cases slightly different due to the those weird differences.\r\n\r\nI wonder if someone can actually explain the difference between ICU and browsers for something like the example above?"}}
{"actor":{"display_login":"caridy"}}