00:30:43  * kpattichajoined
00:42:21  * gibson042quit (Read error: Connection reset by peer)
00:45:10  * gibson042joined
01:17:05  <rkirsling>so I'm just gonna ask this here for good measure before creating an issue, but Yusuke pointed out that the spec is perhaps more conservative than necessary in saying which ISO 8601 time zone designators are allowed in a date time string
01:17:10  <rkirsling>namely
01:17:32  <rkirsling>(as of the latest JSC revision)
01:18:05  <gibson042>in what way?
01:18:15  <rkirsling>JSC / V8 / SM / XS / Ch are _all_ able to handle Date.parse('1970-01-01T00:00:00.000+2300')
01:18:19  <rkirsling>i.e. without the colon
01:18:39  <rkirsling>and JSC / XS / Ch are even able to handle Date.parse('1970-01-01T00:00:00.000+23')
01:18:48  <rkirsling>i.e. just hh without mm
01:19:36  <gibson042>those are implementation-dependent extension that I do not believe should be mandated by spec
01:20:33  <rkirsling>the latter example seems trickier since we'd be requiring something that V8 and SM (and even JSC before today) haven't been doing but
01:21:05  <rkirsling>if all implementations are allowing the dropped colon, I think Yusuke has a point that it would be reasonable to specify it, since it is a part of ISO 8601?
01:21:50  <gibson042>it is only a part of ISO 8601 _basic format_, which drops all punctuation other than the + or - preceding UTC offset
01:21:56  <rkirsling>gibson042: yeah, I do understand that anything beyond what's specified is an implementation-dependent extension but
01:22:05  <rkirsling>hmm
01:22:12  <gibson042>but as noted in RFC 3339, "ISO 8601 is not clear if mixtures of basic and extended format are permissible"
01:22:30  <rkirsling>ohh that's very interesting
01:22:54  <gibson042>YYYYMMDDThhmmss±hhmm is explicitly allowed (basic format), and YYYY-MM-DDThh:mm:ss±hh:mm is explicitly allowed (extended format)
01:23:00  <gibson042>but mixtures are not mentioned
01:23:23  <rkirsling>I see
01:24:02  <gibson042>and the ECMAScript format is based on (and only requires support for) a subset of extended format
01:24:34  <rkirsling>(looking at that RFC, it's also interesting that their `ISO 8601 is not clear on whether an hour of 24 is permissible only if minutes and seconds are 0. This assumes that an hour of 24 is permissible in any context.` is what JSC / XS / Ch do but not V8 / SM)
01:25:40  <rkirsling>gibson042: would you vote then that it's better to stick to just specifying ISO 8601 extended format versus "what's intersectionally allowed by all major implementations"?
01:26:08  <gibson042>yeah, that's a problem in its own right because ISO 8601 only intended hh=24 for the end of a calendar day *within a time interval*, not for isolated date and time of day values
01:26:24  <gibson042>yes
01:26:44  <rkirsling>yeah. I don't think I want to touch the hh=24 thing either 😓
01:26:56  <rkirsling>okay, I can convey that back then
01:27:17  <gibson042>others may disagree, of course
01:27:19  <rkirsling>context was https://bugs.webkit.org/show_bug.cgi?id=160287 if you're curious
01:30:38  <gibson042>"The end of day representation, where [hh] has a value of [24], shall not be used for a single time point." /whoops
01:31:25  <gibson042>but yeah, certainly not intended for use with nonzero minutes/seconds/subseconds
01:32:53  * gibson042quit (Quit: Leaving.)
01:33:06  <rkirsling>right
01:33:13  <rkirsling>pretty awkward 😓
01:40:52  * kpattichaquit (Ping timeout: 268 seconds)
01:47:21  * droussoquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:02:31  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:04:18  * droussojoined
02:12:58  * droussoquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:15:27  * keith_millerjoined
02:17:37  * acagastyajoined
02:26:17  * keith_mi_joined
02:28:50  * keith_millerquit (Ping timeout: 240 seconds)
03:14:51  * cybai_quit (Remote host closed the connection)
03:15:25  * cybaijoined
03:19:52  * cybaiquit (Ping timeout: 260 seconds)
03:30:22  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:56:22  * cybaijoined
04:27:07  * acagastyaquit (Quit: Connection closed for inactivity)
04:39:33  * jmdyckquit (Quit: Leaving.)