Why input string format matters for JavaScript (and moment.js) dates

Why input string format matters for JavaScript (and moment.js) dates

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

Try it:

new Date('2017-05-01')

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,

new Date('2017-5-01')

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:

new Date('2017/05/01')

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.

More on this at “JavaScript Date: a Bad Part”, https://jj09.net/javascript-date-a-bad-part/, by Jakub Jedryszek.

JavaScript Date vs. Moment.js

This came up today as I was debugging some Moment.js date/time library warnings. The recommended ‘YYYY/MM/DD’ format of the date string param, which gives us what we want from the JavaScript 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.

Moment('2017/05/01', 'YYYY/MM/DD')

Midnight-minus-one-hour Conclusions

  • 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.js for some line/series charts. TDD, which had seemed a bit costly here, actually cut short the guesswork today).

3rd-party code still needs tests

[ original gist 28 March 2013 ]

“If there are no tests, it does not work,” a former colleague said, who could have added, “whether your code or someone else’s.”

I’m not the first to say it but it needs re-stating: 3rd-party libraries are no guarantee that your code continues to behave as expected.

If one of the duties of your work is making sure you’re not introducing bloat or cruft or inefficiencies or bugs or unexpected behavior, then you’re cutting corners if you don’t have tests, whether you use 3rd-party code or not.

Continue reading