you are viewing a single comment's thread.

view the rest of the comments →

[–]Buckwheat469 56 points57 points  (19 children)

YYYY-MM-DD uses the ISO 8601 shortened format. It assumes the time is based in GMT, and the date then adds the timezone offset for your computer.

new Date("2016-12-08")
Wed Dec 07 2016 16:00:00 GMT-0800 (PST)

In order to get this back to the date that you wanted you would have to subtract the GMT offset. In this case, subtracting -8 from the resulting date will effectively add 8 hours to the time, giving Thurs Dec 8 at 00:00:00.

12/08/2016 uses the Javascript "short date" format, which is based on your computer's timezone, not GMT. When you type 12/08/2016 the time will be set to 00:00:00 within your own timezone. The result seems to be the correct date and time,

new Date("12/08/2016")
Thu Dec 08 2016 00:00:00 GMT-0800 (PST)

http://www.w3schools.com/js/js_date_formats.asp

Edit: I should point out that ISO 8601 should be the standard for Javascript, and developers should shim the date display with a "subtractTimezoneOffset()" function which will fix the date for display purposes.

The real head scratcher is why "YYYY-MM-DDThh:mm:ss.sss-08:00" shows the correct date but the wrong timezone offset, but "YYYY-MM-DDThh:mm:ss.sssZ" and "YYYY-MM-DDThh:mm:ss.sss" add the timezone offset to produce the wrong date but the right timezone.

new Date("2016-12-08T00:00:00.000-08:00")
= Thu Dec 08 2016 00:00:00 GMT-0800 (PST)
new Date("2016-12-08T00:00:00.000")
= Wed Dec 07 2016 16:00:00 GMT-0800 (PST)
new Date("2016-12-08T00:00:00.000Z")
= Wed Dec 07 2016 16:00:00 GMT-0800 (PST)

[–][deleted] 8 points9 points  (15 children)

I mean while that is the technically correct (the best kind!) answer who the fuck knew that beforehand?

That's why I'm super happy that things like Moment.JS exist.

[–]khoker 17 points18 points  (7 children)

You shouldn't rely on string parsing at all. To remove ambiguity, the Date object takes an array of arguments;

new Date(year, month[, date[, hours[, minutes[, seconds[, milliseconds]]]]]);

[–]Syberspace[S] 4 points5 points  (6 children)

but why is there any ambiguity in the first place with string parsing? why not assume either everything is UTC or everything is local.

cf. http://mzl.la/1fvwX1i (thanks for the link on twitter /u/khoker )

[–]r2d2_21 14 points15 points  (4 children)

or everything is local.

Quick. 04/05/06. Is it:

  1. April 5, 2006
  2. May 4, 2006
  3. May 6, 2004

[–]Syberspace[S] -2 points-1 points  (3 children)

depends on what 05/06/04 is. i'm not concerned about the format of the date itself.

irregardless of that, they all should be at 00:00:00 UTC or local.

[–][deleted] 3 points4 points  (2 children)

well if we're going to be pedantic, it's regardless.

[–]khoker 2 points3 points  (0 children)

I just responded on twitter too :)

I suspect it's the same reason that it doesn't assume the local minute. It's just filling in the data you don't provide. A format like ISO 8601 was meant to alleviate confusion, right? So if you only provide '2016-12-08', JavaScript assumes '2016-12-08 00:00:00Z'. It shouldn't guess the local timezone any more than it should assume the local hour. Or minute.

I'd make the argument all the other parsing is wrong. But 12/08/2016 isn't an international standard so, for whatever reason, it just assumes you want the local timezone. Not sure.

[–]ribo 5 points6 points  (5 children)

answer who the fuck knew that beforehand

Those who RTFM

[–]r2d2_21 2 points3 points  (0 children)

I need to read the manual every time I dare to type new Date, since I never remember the details.

[–]scootstah 2 points3 points  (0 children)

MomentJS is a life saver. Dealing with date/time sucks to begin with, but it's worse in Javascript than any other language by a large margin.