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).

Using only Month and Year in jQueryUI Datepickers

User interface components in general are built with an expected user behavior.
We used the jQuery-UI datepicker, to save time, but in an unusual way, which
cost us a lot of time discovering what we’d missed. We re-learned a key insight,
namely, month and year are navigation, not selection controls.

The rest of this post describes the implications we worked out. Short version
of the code is at the bottom of this post. There are other files attached in a gist version of this post at https://gist.github.com/dfkaye/f1efc4be64699df2d65c55e27b41f725


Recently (November 2016) we ran into a design requirement that a dashboard report should cover a time period, with start and end dates and that the report should update when users change a month or a year in either the start or end datepicker.


In the interest of saving time, rather than roll our own control for that, we
chose to use the JQueryUI datepicker for each of these, but with an unusual
approach that we would not show the calendar control (the table with all the
clickable date links).

Of course, that unexpected approach led to unexpected and undesired behavior.


In our implementation, we used changeMonth: true and changeYear: true in the
datepicker(options) argument, in order to display the month and year “
elements, and set let the datepicker display “inline” (i.e., always, without a
dialog – see http://jqueryui.com/datepicker/#inline).

We also set the defaultDate to the current year and month, and use 1 as the
day, so that we’re always comparing the first of any month.

We also needed to keep the two datepickers synchronized, such that a user could
not set the start date to something greater than the end date. We do that in the
onChangeMonthYear handler, re-setting either start’s maxDate or end’s
minDate after a change to the end or the start date, respectively.


The prev and next arrows worked just fine, as they are decrement/increment
handlers only. But we noticed that sometimes the onChangeMonthYear handler
was called multiple times when we changed a date by using the month and year
select elements. For example, we’d change the start year, then change the
end year. On that second change, we’d see the update to the start date’s
maxDate – which seemed to trigger a onChangeMonthYear call to the start
datepicker again, even though the start element had not been touched.
The result was that date ranges became unpredictable, even un-navigable.


It turns out the onChangeMonthYear event results only in re-drawing the
calendar – it does not calculate a new date selection.

Translation: month and year are navigation controls; the calendar’s date links are the selection controls.

The expected behavior in the datepicker is that users select a date link inside
the calendar. Because we are not using the calendar, we have to re-set the date,
in code, on the datepicker for which the onChangeMonthYear handler is called –
every time.

You can see most of the code fragments necessary to make the whole thing go by
looking at the other files posted in this gist. Here’s the condensed version of
the JavaScript we used:

onChangeMonthYear: function (year, month, instance) {

  // Build a new Date from the display date, decrementing the display
  // month by 1 for use in JavaScript's built-in Date().
  var newDate = new Date(year, Number(month) - 1, 1);

  // This one line prevents the buggy behavior noted above.
  $(instance.input.context).datepicker('setDate', newDate);


This took quite a bit of time to reason out, but that’s all there was to it.

Pseudo-Comments in CSS (Or, How Browsers Parse Styles)

The CSS spec does not mention it, but you can mimic C-style and/or unix-style line comments in CSS files (with some caveats). Others have written about them before (see in particular, SitePoint’s Web Foundations post covering CSS Comments). The present post examines them in further detail.

[Note: Thanks to Louis Lazaris and Web Tools Weekly, this post was originally published on October 21, 2015, at http://www.sitepoint.com/pseudo-comments-in-css-or-how-browsers-parse-styles/. It is actually a follow-up (slightly modified) to my earlier post on CSS line rule comments. ]

Continue reading

Constructor Inheritance in JavaScript

[ originally posted 12 Feb 2013 ]

Note: this post acts as justification for my Constructor kata on github. It’s really a re-post for posterity, as 1) I thought it worth preserving a specimen of my former thinking, because 2) I think far less often in the constructor/super inheritance pattern in JavaScript than I did even a year ago (i.e, summer of 2014).

Continue reading

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