Closed UnicodingUnicorn closed 5 years ago
@UnicodingUnicorn
Thanks but I think the problem is still here because we use timeParse
for custom formats. And we rely on these format strings not compatible with moment.js
Any chance we can make timeParse
raise these errors?
@roll I believe that this problem is mentioned in d3/d3-time-format#47. I don't think timeParse
can, or will, raise an error now or in the future.
As an aside, may I ask why the decision to use an additional library? As far as I can see, moment.js
time parsing offers similar functionality, albeit with different syntax.
@UnicodingUnicorn Thanks for the information. Datetime objects in JavaScript is a joke... Yea, I don't see how it can be resolved for custom datetime-formats.
Regarding the syntax - this library is an implementation of the Table Schema spec along with other 8 implementations. So on the lib level, we don't choose what syntax to use. And the reason is interoperability between different platforms.
Overview
What it says on the tin. Resolves #114. What was happening was that
moment.js
actually catches and throws errors on such things just fine, just thatd3-time-format
changes the supplied date to the next closest valid one, creating the error as described.I changed it so that
default
uses amoment.js
format string to parse the date, rather than using thetimeParse
ofd3-time-format
.fmt
remains the same. I also chucked in a couple of tests for short months and leap dates.Please preserve this line to notify @roll (lead of this repository)