Closed thomas-riccardi closed 11 years ago
First of all, equal is doing exact comparison with ===. Date is reference type and will be compared by reference, that is why it will not work there.
I updated the example to use eql
.
In fact in my real use-case I use above
, but I thought it would be simpler to use equality in the example.
:+1:
I see 2 options here: use Date#toISOString or write own formatting function. I prefer first way, as it is native. What do you think?
Ideally we would need a Date#toLocaleString
with milliseconds, but it doesn't seem to exist.
Going with a manual formatting we would only be able to simulate one locale, not the others.
So Date#toISOString
seems the best way indeed.
About manual formatting we can use getTimezonOffset (tz names of course not available)
Yes but it will only emulate part of the localized version, if we go this way why not adding more? And this will lead to a copy of one locale, with milliseconds. And we can't do anything for the other locales.
Date#toISOString
is a simple and correct solution, although it's less readable...
This code fails (which is expected) and throws an Error with printed Dates:
This is confusing because the two dates are the same. This happens because the current string representation of the Date doesn't use milliseconds.
Either always display milliseconds, or at least display them when the two strings are equal without milliseconds, to remove the ambiguity.