We had one guy at a previous job responsible for hunting down the ins and outs of time management with JavaScript clients (well, and our C# server-side), and I remember him basically boiling down what he'd found to, "Dates are a pain." One level more technical than that: "Convert everything to UTC immediately, all the time, except for the final step before displaying to the user."

I've worked with dates enough to know he wasn't kidding, but this takes the cake:

Differences in assumed time zone

Given a date string of "March 7, 2014", parse() assumes a local time zone, but given an ISO format such as "2014-03-07" it will assume a time zone of UTC. Therefore Date objects produced using those strings will represent different moments in time unless the system is set with a local time zone of UTC. This means that two date strings that appear equivalent may result in two different values depending on the format of the string that is being converted (this behavior is changed in ECMAScript ed 6 so that both will be treated as local).

Seems a better fix for ES6 would be to have parseLocal() and parseUTC() (or even a parseISO() and parseColloquial(), if you're not into the whole brevity thing) with a legacy parse() sticking around to keep acting consistently wonky [sic].

With public APIs comes public responsibility. And once you release v1, you've largely already sunk yourself. You will find mistakes, and you will have to fix them with an eye on preserving "wrong" legacy behavior.

I hate breaking "fixes" like this one just a little bit more than bizarre, hard to understand, initial decision like, well, this one.

Labels: ,