see original gist, 2017-06-17, at https://gist.github.com/dfkaye/e46b2f44ea5f624224602b51a7d4f6bb#file-why-format-matters-md
Given this format, ‘2017-05-01’, I want the date of May 1, 2017
Turns out that
Date() processes that format as UTC based, not local based.
And that returns
Sun Apr 30 2017 17:00:00 GMT-0700 – 7 hours behind – which is not what we want.
Try it without the leading zero on the month,
and that returns
Mon May 01 2017 00:00:00 GMT-0700 which is what we want.
Try it with stroke/slash characters in place of the hyphens:
That works, too:
Mon May 01 2017 00:00:00 GMT-0700
Recommended format: YYYY/MM/DD
Recommended format for parsing is: YYYY/MM/DD – user local settings independent. It always assumes local timezone offset for date string given as a parameter.
This came up today as I was debugging some
Date() constructor, produces something unexpected in Moment.
Result is a long console warning.
Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non RFC2822/ISO date formats are discouraged and will be removed in an upcoming major release. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info.
Turn that off by using Forgiving Mode, i.e., by adding a second parameter, indicating the format, possibly “non-standard”, to be expected by Moment.
- Specifications (RFC2822/ISO) and implementations (
Date(), Moment.js) are two different things.
- Time formatting is really hard to codify once and be done with.
- It can take a lot of time to read up and understand the issues completely.
- (Author’s message) Use test-driven development to catch this stuff. I first detected these issues today using TDD (For the record, I’m transforming a JSON response into a proper structure to be consumed by
d3.jsfor some line/series charts. TDD, which had seemed a bit costly here, actually cut short the guesswork today).