Live data from Hacker News

Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

brandondong.github.io

31–40 of 167 posts

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#31
post #12
post #7

Hang on, slashes and year-month-day? https://en.wikipedia.org/wiki/ISO_8601 Handed down by the ISO, The Great Compromise allows YYYY-MM-DD (or YYYYMMDD if you're in a hurry) but the version with slashes I'd find ambiguous and upsetting, especially early in the month. The standard is good, and you can get it from `date -I`. Hell mend anyone who messes with the delimiters or writes the year in octal or any other heresy…

Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.

Proer tip: never use anything but unix timestamp until presentation.

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#32
post #6

How did they manage to build the entire modern Web on a language without a standard library?

Because the alternative would have been VBScript (if Microsoft had won at the time).

JS was a compromise. It had to be sent out the door quick, it needed to look sufficiently like Java to not upset Sun who were trying to establish Java as the universal platform at the time while not being feature complete enough to be perceived as a competitor rather than a supplement. And it had to be standardized ASAP to pre-empt Microsoft's Embrace Extend Extinguish strategy (which was well on its way with JScript). That's also why it's an ECMA standard rather than ISO despite Netscape not having been based in Switzerland - ECMA simply offered the shortest timeline to publishing a standard.

I think what's more amazing isn't just how we managed to build the bulk of user interfaces in JavaScript but how we Node.js managed to succeed with ECMAScript 3. Node.js was born into a world without strict mode and without even built-in support for JSON: https://codelucky.com/javascript-es5/ - and yeah, ECMAScript 3 was succeeded by ECMAScript 5 not 4 because it took vendors 10 years to agree on how the language should evolve in the 21st century - not only did we build the modern web on JavaScript, we built a lot of the modern web on the version of JavaScript as it was in 1999! Even AJAX wasn't standardized until 2006 when Web 2.0 was already in full swing.

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#33
post #8

Earlier quoted context omitted.

The world where JavaScript has a robust standard library is one where there is only one browser vendor who gets to call all the shots regarding what the web looks like. That is not a better world.

Kind of funny that you think the open web still exists. I mean, even Microsoft gave up and just went with Chromium, and they got the definition of almost infinite resources at their disposal. Effectively if your website doesn't run in Chrome and Safari, it won't be seen by 99% of the market.

> even Microsoft gave up

Ah yes, Microsoft, the defenders of the free world.

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#35
post #30

Earlier quoted context omitted.

RFC3339. ISO 8601 allows for 2 or 6 digit years. Truncating to 2 is just incorrect, and 6 digits is absurd. And you can read the RFC without paying ISO - and you can discuss the RFC with people who have also read it instead of relying on people using the Wikipedia page to interpret and explain ISO 8601. I have a scheduling service at work and I keep getting requests for implementing ISO 8601 timestamps but I ignore t…

There's this handy venn diagram that I've seen floating around for a long time. Just found a random link to it with an image search: https://gyazo.com/d8517f72e24c38f055e17182842b991c/max_size/... ISO 8601 does have some strange formats...

That's a screenshot of this website:

https://ijmacd.github.io/rfc3339-iso8601/

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#37
post #12

Earlier quoted context omitted.

Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.

RFC3339. ISO 8601 allows for 2 or 6 digit years. Truncating to 2 is just incorrect, and 6 digits is absurd. And you can read the RFC without paying ISO - and you can discuss the RFC with people who have also read it instead of relying on people using the Wikipedia page to interpret and explain ISO 8601. I have a scheduling service at work and I keep getting requests for implementing ISO 8601 timestamps but I ignore t…

I believe two-digit years haven't been allowed for a while:

> ISO 8601:2000 allowed truncation (by agreement), where leading components of a date or time are omitted. Notably, this allowed two-digit years to be used as well as the ambiguous formats YY-MM-DD and YYMMDD. This provision was removed in ISO 8601:2004.

(That's from https://en.wikipedia.org/wiki/ISO_8601 - I don't have the standards handy, ironically.)

Honestly I'm happy with either the RFC or ISO, but it seems like most normies haven't heard of RFCs so ISO is my default.

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#38
post #31
post #12

Earlier quoted context omitted.

Pro tip: never ever use anything but ISO dates in UTC tz unless you're displaying it for a user in a UI.

Proer tip: never use anything but unix timestamp until presentation.

Even more proer tip: only use binary representations of variables until presented to the user.

Re: Why are 2025/05/28 and 2025-05-28 different days in JavaScript?

#39
post #13

In Sweden, we can write dates as 28/5-25

As another swede, I dare you!

We swedes use standardized ISO 8601 dates such as YYYY-MM-DD as dictated by our excellent government and you find it in use in our social security number, government correspondence and mostly everywhere.

Post reply on HN