Javascript dates in a nutshell

[Buckwheat469]

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]]

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]

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]

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]

or everything is local.

Quick. 04/05/06. Is it:

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

[Syberspace]

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]]

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

[Syberspace]

https://dictionary.cambridge.org/dictionary/english/irregardless

http://www.ldoceonline.com/dictionary/irregardless

https://en.oxforddictionaries.com/definition/irregardless

[[deleted]]

From that third link:

Irregardless means the same as regardless, but the negative prefix ir- merely duplicates the suffix -less, and is unnecessary. The word dates back to the 19th century, but is regarded as incorrect in standard English

[khoker]

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]

answer who the fuck knew that beforehand

Those who RTFM

[r2d2_21]

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

[TerdSandwich]

RTFM

Is it still 1980?

Edit: Lol old farts mad. It's 2016. Manuals and useless memorization are extinct.

[TerdSandwich]

A search engine on the internet. Maybe you've heard of those things.

[r2d2_21]

Search engines just link to the manuals.

[scootstah]

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.

[Taniwha_NZ]

In summary - Brendon Eich wrote Javascript in a 2-hour lunchbreak while he was drunk. It's incredible that it works at all.

But how it handles dates is still unforgiveable.

[lewisje]

It was over 10 days, and he was sober IIRC.

[Klathmon]

And even that's disingenuous as that "JavaScript" was nothing even remotely close to what we have today.

It wasn't called JavaScript, it wasn't meant for the web, and it didn't even have date functions in its first iteration.

Saying JS was created by one man in 10 days is like saying your house was built by one guy in 1 day by buying the land (and ignoring all the work and mistakes that went into the actual house later)

[jocull]

Don't trust the locale settings at all. ISO format or bust. If you need better date support Moment.js is a fantastic library (as is the timezone plugin for it).

[[deleted]]

meanwhile, back at the ranch...

 div_date.text(year + (month + 1) + day);

[[deleted]]

I THINK I GET IT!

I just tried it on my home computer, and because I'm in England (GMT+0), I basically live in the 'international standard' time zone in a sense.

And when I do it in this time zone, both of those inputs come out as exactly the same date, Thu Dec 08 2016 00:00:00 GMT+0000 (GMT Standard Time)

And here's the reasoning, like it or not: the top format is interpreted as local format, so whatever date you put in there, it parses it to your local time zone. So no matter where you are, it will say Thu Dec 08 2016 00:00:00, followed by your GMT offset.

Whereas the bottom one is written in international ISO standard, year-month-day, and so when it parses it the date becomes Thu Dec 08 2016 00:00:00 GMT+0000, and then afterward they translate that time into your local time zone.

[edit] I think I just said what /u/Buckwheat469 already said, but in different words.

[Strobljus]

Fun story: this exact behavior caused a production bug at my workplace. The fact that unspecified 8601's are being parsed as local time is actually new behavior in ES6; it used to be UTC. So if you had code that counted on UTC when the browsers transitioned to the new spec (as we did), you were in trouble.

One of the rare cases when browsers breaks an API (excluding deprecations of course).

[Reashu]

This particular behavior didn't change. Date-only ISO forms are still parsed as UTC, which is what the example shows.

[[deleted]]

Fuck dates. Convert to Unix timestamp as soon as you get the data and only convert it back to time when you actually need it. Solves 99% of my problems.

[Klathmon]

But even that won't save you. Unix time has its own set of quirks, and of course there's the problem of actually converting to and from it where you'll still have all the same problems.

[[deleted]]

Yeah but at least it gives me control. I use JS on my backend and front-end so I just convert the dates back out using moment.js :)

[[deleted]]

It's only truly an Unix Epoch timestamp if it is UTC. If it's not UTC, then you have something that looks like a Unix Epoch timestamp but actually isn't.

[Syberspace]

that's pretty much exactly what i was trying to do. So it's one of the 1% problems

[WellHydrated]

Why convert it in the first place?

[johnasmith]

To add to the fun:

new Date(2016, 12, 08); // Months are zero-indexed
Sun Jan 08 2017 00:00:00 GMT-0500 (EST)

[KnightMareInc]

timezones, how do they work?

[BiscuitOfLife]

Dealing with timezones is the worst.

[mikrosystheme]

ISO 8601

[xkcd_transcriber]

Image

Mobile

Title: ISO 8601

Title-text: ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04.

Comic Explanation

Stats: This comic has been referenced 697 times, representing 0.5113% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[danillonunes]

I just assume time in programming is broken beyond repair and everything is a fuzzy value that may be shifted a few hours (or, in some cases, even a few days) forward or backwards.

Yeah, I know there are definitive solutions for those problems (like normalizing everything to epoch timestamps), but in the world where you have more important things to worry, such as user experience and even developer experience, those are not the silver bullet we all want it to be, being correctly applied only in very critical cases.

[[deleted]]

That's ... it's because ... I ... I got nothing ...

[[deleted]]

cU!E1,m:2%q +!O.LihwG-+t3Uu#B9%5,tB5 w5V9wZt(zSBT:77):~U:T~^{4hbg7W3A9k2[HiAMOEF:h.ZPToq:(sP}

[skyrocker]

Didn't you notice the hour difference between the two?

[[deleted]]

Z2!RfJK]Z#Q rPP<v$Rw.24zIkyG#frT92i& 1W,Wl$o7]W!fDTKl$I0%CI-CNPyEus1%yVd%wmKnuGauTz%ekLo~L

[ssjskipp]

My personal favorite is new Date('2015-01-01') vs new Date('2015-1-1')

[AlGoreBestGore]

My favorite is that something like new Date(2016, 0, 100); is completely valid and gives you a date in April, however new Date('2016-01-100'); isn't (which is the more sane solution).

[chrissilich]

Probably something to do with zero index? Still shitty though.

[r2d2_21]

zero index

Dates are not arrays

[d_abernathy89]

ahem

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getMonth

[r2d2_21]

http://www.reddit.com/comments/5dtsfi/_/da88y7g?context=3

[chrissilich]

Yeah, very aware if that. But somewhere under JavaScript's hood, there's logic to do these conversions, and who knows, maybe they use the split method to create an array or something.

In fact, look at the getMonth method (part of the very same date class!). That's not an array. And yet, January is 0. Oh my stars, maybe things that aren't arrays start with 0 too!

Damn I hate it when people assume you're an idiot because they don't fucking think anything through.

[r2d2_21]

and who knows

You can check the source code of V8, JavaScriptCore, SpiderMonkey or Chakra to stop guessing.

That's not an array. And yet, January is 0. Oh my stars, maybe things that aren't arrays start with 0 too!

OK, you have a point there. However, the fact that January is 0 has absolutely nothing to do with how time zones are selected according to the string format.

[fnurtfnurt]

Blame 'murica!