{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/proposal-temporal/issues/39","repository_url":"https://api.github.com/repos/tc39/proposal-temporal","labels_url":"https://api.github.com/repos/tc39/proposal-temporal/issues/39/labels{/name}","comments_url":"https://api.github.com/repos/tc39/proposal-temporal/issues/39/comments","events_url":"https://api.github.com/repos/tc39/proposal-temporal/issues/39/events","html_url":"https://github.com/tc39/proposal-temporal/issues/39","id":242855367,"number":39,"title":"Parsing ISO 8601 strings","user":{"login":"gilmoreorless","id":159415,"avatar_url":"https://avatars3.githubusercontent.com/u/159415?v=4","gravatar_id":"","url":"https://api.github.com/users/gilmoreorless","html_url":"https://github.com/gilmoreorless","followers_url":"https://api.github.com/users/gilmoreorless/followers","following_url":"https://api.github.com/users/gilmoreorless/following{/other_user}","gists_url":"https://api.github.com/users/gilmoreorless/gists{/gist_id}","starred_url":"https://api.github.com/users/gilmoreorless/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gilmoreorless/subscriptions","organizations_url":"https://api.github.com/users/gilmoreorless/orgs","repos_url":"https://api.github.com/users/gilmoreorless/repos","events_url":"https://api.github.com/users/gilmoreorless/events{/privacy}","received_events_url":"https://api.github.com/users/gilmoreorless/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2017-07-13T23:10:28Z","updated_at":"2017-07-27T19:55:50Z","closed_at":null,"body":"The discussion in #34 about maintaining precision between server and client got me thinking about transport formats. I added a comment on #25 about serialising `temporal` objects to JSON output, but what about the reverse? When the server outputs a datetime in ISO 8601 format, we'll need a way to convert that string into a `temporal` object.\r\n\r\nThe different `temporal` objects will have different requirements (e.g. `PlainDate` aka `CivilDate` will have no use for any of the time parts). Additionally, ISO 8601 strings can be variable length, omitting various parts of precision.\r\nThis is mostly thinking out loud (or the text equivalent), so I don't have a solid proposal, just more questions:\r\n\r\n* Do we allow each `temporal` object type to parse an ISO 8601 string and throw away the parts that are not needed? Would this just cause more confusion than it's worth when `CivilTime` ignores a time zone present in the input?\r\n* Do we define a top-level `temporal.parseISOString()` method (name is up for debate) that returns the appropriate object depending on the string format?\r\n```js\r\ntemporal.parseISOString('2017-07-14');\r\n// == CivilDate(2017, 7, 14)\r\n\r\ntemporal.parseISOString('2017-07-14T07:54');\r\n// == CivilDateTime(2017, 7, 14, 7, 54)\r\n\r\ntemporal.parseISOString('2017-07-14T07:54:00+10:00');\r\n// == CivilDateTime(2017, 7, 14, 7, 54, 0)  TBC\r\n```\r\n* Do we allow parsing more information than provided by ISO 8601, in order to accurately map the time zone? The current proposal shows an example of a `ZonedInstant` being represented as `2017‑12‑31T09:00:00+09:00[Asia/Tokyo]` — the extra zone information is very useful here, and it would be ideal to be able to parse the string output of any `temporal` object back into an identical object, thus reinforcing the immutability.\r\n\r\n_(As a side note/rant, I find the lack of named zone support in ISO 8601 really frustrating. Although it's understandable, given the lack of official standard (IANA zones notwithstanding, but they're still just a defacto standard rather than an official one). For example, a timestamp for where I live can only define the zone as `+1000` / `+10:00`, which could be for Sydney, Brisbane or even Vladivostok.)_\r\n\r\nThere are complications and edge cases no matter which way it's done, but I think that defining a 2-way serialisation is important. Without it, the usefulness of the `temporal` module will be greatly diminished.\r\n\r\n(Of course, this is the generally the point where someone smarter than me comments with a solution that seems perfectly obvious in hindsight. 😉 )"},"comment":{"url":"https://api.github.com/repos/tc39/proposal-temporal/issues/comments/318469053","html_url":"https://github.com/tc39/proposal-temporal/issues/39#issuecomment-318469053","issue_url":"https://api.github.com/repos/tc39/proposal-temporal/issues/39","id":318469053,"user":{"login":"icambron","id":244988,"avatar_url":"https://avatars3.githubusercontent.com/u/244988?v=4","gravatar_id":"","url":"https://api.github.com/users/icambron","html_url":"https://github.com/icambron","followers_url":"https://api.github.com/users/icambron/followers","following_url":"https://api.github.com/users/icambron/following{/other_user}","gists_url":"https://api.github.com/users/icambron/gists{/gist_id}","starred_url":"https://api.github.com/users/icambron/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/icambron/subscriptions","organizations_url":"https://api.github.com/users/icambron/orgs","repos_url":"https://api.github.com/users/icambron/repos","events_url":"https://api.github.com/users/icambron/events{/privacy}","received_events_url":"https://api.github.com/users/icambron/received_events","type":"User","site_admin":false},"created_at":"2017-07-27T19:55:50Z","updated_at":"2017-07-27T19:55:50Z","body":"That does seem reasonable"}}
{"actor":{"display_login":"icambron"}}