From:  Chris Peterson <>
Date:  10 Jun 2016 05:39:12 Hong Kong Time

Re: Improving Date.parse


And spec'ing the union of every browser's quirks is not practical. 
Chrome's implementation, in particular, is very lenient, even accepting 
"JanZ ..Zu.aZ.r.Zzy.Z . 1 .... 2016" as 2016-01-01.

On 6/9/16 2:09 PM, Jim Blandy wrote:
> The more I think about this, the more I'm coming around to Shaver's 
> position. The volume of code on the web is such that it's not a bad 
> first approximation to just think of it as a complete cover of every 
> observable behavior the APIs exhibit. And so much of it is poorly 
> maintained, or not actively maintained at all. So changing anything at 
> all is just guaranteed to break things that will never get fixed.
> Adding a new method doesn't make people notice it or use it. People 
> will still crib from old code that calls the Date constructor. But 
> that's the status quo; you haven't made anything worse than it is 
> already. And for actively maintained code, web developers are used to 
> tracking progressing standards, and knowing what the modern thing to 
> use is; a new Date method will participate in that process like 
> everything else. Consider how well moment.js has been picked up, even 
> as a third-party library.
> Following the "complete cover" principle, adding a new method to Date 
> is going to break something too: there's guaranteed to be crazy code 
> that somehow depends on the new function not being there. But that's 
> going to be a much smaller impact than changing the behavior of 
> something ancient and widely used, like the Date constructor.
> On Thu, Jun 9, 2016 at 1:25 PM, Jim Blandy  > wrote:
>     I certainly get the argument in favor of new APIs over changes to
>     old APIs.
>     But when an API behaves inconsistently from one browser to the
>     next, it seems to me the argument for preserving its specification
>     gets a lot weaker. ECMAScript has pinned down under-specified
>     behaviors plenty of times.
>     On Thu, Jun 9, 2016 at 11:54 AM, Mike Shaver
>     > wrote:
>         I agree with the motivation of the proposal: provide reliable
>         cross-browser date parsing capability. The choices are:
>         - change the behaviour of an existing, fragile API
>         - add a new API with well-specified behaviour
>         To take advantage of the former case, a program must know that
>         it's running in an engine that has updated to the spec, by
>         version checks or (less likely on the web, IMO) probing with
>         known patterns. To be damaged by the former case, it need only
>         trip over an edge case that was deemed insignificant.
>         To take advantage of the latter case, a program must also know
>         that it's running in an engine that has update to the spec,
>         but it can do that through feature testing. A program can't be
>         damaged by the latter case.
>         I am in favour of the latter case.
>         Mike
>         On Thu, Jun 9, 2016 at 11:49 AM, Jim Blandy
>         > wrote:
>             I'm not sure where you're going with this, other than,
>             yes, any observable change to an API can have a negative
>             impact. Making behavior consistent across browsers often
>             has a positive impact as well.
>             Do the observations you made suggest ways to improve the
>             proposal?
>             On Thu, Jun 9, 2016 at 11:43 AM, Mike Shaver
>             > wrote:
>                 On Thu, Jun 9, 2016 at 11:42 AM, Jim Blandy
>                 > wrote:
>                     The current behavior varies from one browser to
>                     another anyway. Assuming the new grammar only
>                     codifies existing practice, won't any such
>                     programs already be behaving inconsistently across
>                     browsers?
>                 Many programs adapt to the browser they're running in.
>                 Mike