From:  Morgan Reece <winter2718@gmail.com>
Date:  10 Jun 2016 04:11:08 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: Improving Date.parse

NNTP-Posting-Host:  63.245.214.181

Thank you for the additional issues to consider. The existing API is indeed
fragile but for the moment I'm optimistic that we can create a drop in
replacement with minimal issue. I prefer this approach because leaving `new
Date(...)` the way it is will not address the inconsistencies which are our
root problem, the web will still be broken. Asking developers to use a new
API for cross compatibility is not much different than asking them to stick
to ISO 8601.

If my optimism turns out to be unfounded I would support proposing that a
new parser be implemented as `Date.parse` while leaving `Date`'s
constructor essentially unchanged. However if we can do better than that,
and I currently believe we can, we should.

2016-06-09 11:54 GMT-07:00 Mike Shaver :

> 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
>>>
>>>
>>
>