New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
null is a valid date #537
Comments
It not as straightforward as it looks. In ECMAScript, new Date(null)
//=> "Thu Jan 01 1970 04:00:00 GMT+0400 (+04)"
new Date(0)
//=> "Thu Jan 01 1970 04:00:00 GMT+0400 (+04)"
// but:
new Date(undefined)
//=> "Invalid Date"
new Date('asd')
//=> "Invalid Date" This behavior is consistent across all date-fns functions, so if you add a day to The library sticks to ECMAScript behavior, even in edge cases like this one. It could sound controversial, but it ensures consistency both across date-fns API and with ES. Initially, I wanted to close this issue as "Won't fix", but there is a nuance that stops me: there is no such thing as Please share your thoughts. |
IMHO: since so, i think, |
I think |
I think |
Having built a few date pickers the native New Date behavior around null has only ever caused bugs. DateFns is good place to adjust these unintuitive native behaviors. I'd vote for null to be not a valid a date |
I think date-fns has the opportunity here to correct the spec; my vote, like the above others, is for |
Is there any known example of |
For me as well, A reason for creating a library in the first place is to make reasoned 'fixes' and normalisations to bizarre behaviours in the underlying language in my opinion anyway. |
I agree with the popular sentiment in this thread -- unless there are some solid practical reasons that we can enumerate (as suggested by @bpierre), |
I agree with pretty much all that was said before, especially with @ai comment. |
Some API design would set some time field to null if there is some abnormal
situation
Pierre Bertet <notifications@github.com>于2017年9月12日 周二20:15写道:
Is there any known example of null being used for a good reason, using new
Date or date-fns? If not, I vote for null not to be valid.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#537 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAedXnmDPXW0kl3_2iif2VFsIKRfRd7vks5shnXkgaJpZM4Oud2W>
.
--
sent via Inbox app :)
|
For what it's worth, Moment's behavior invalidates I don't recall any GitHub issues where people complained about this. I think it would be safe to move forward by having |
Note: I'm looking at the ECMAScript spec, and while it is indeed the case that If you wish to bikeshed this for the future of JavaScript - I threw an issue in the Temporal proposal to address: tc39/proposal-temporal#49 |
I agree in considering ‘new Date(null)’ as an invalid value. Truthy and falsely values are a bit cumbersome in JS. |
Unless the value implements the Date interface (via prototype) or is a string/JSON representation of a valid Date, IMO it's not a Date. Null does neither. |
I agree with most of the comments. Null shouldn’t be a valid valid to create a date. It’s the reason of several bugs that are hard to track. This is a great opportunity to solve that. My two cents. |
Thanks, everyone who replied! It's great to see unity about the issue, I'll go through API and apply this change everywhere. |
The fix is released |
Seemed like unexpected behavior to me.
The text was updated successfully, but these errors were encountered: