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

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

How is slashes ambiguous if you use YYYY and in YMD order?

The standard is... well, it IS indeed a standard, I guess you can't really argue that, but it's a very great deal more permissive than many people might hope or expect. https://ijmacd.github.io/rfc3339-iso8601/ is a wonderful illustration of some of the deeply silly time formats permitted by ISO 8601.

> Hang on, slashes and year-month-day?

I believe slashes are the most common separators in Japan (which uses that order), at least when explicit kanji for "year", "month" and "day" aren't used.

> it needed to add a time (midnight, that's sane)

Is it sane? Is midnight at the start of a day, or the end of it? I'd think noon would be less ambiguous, and significantly less prone to these timezone issues (although this may not be a benefit).

> on a language without a standard library?

Because the other languages & with bigger runtimes and more comprehensive standard libraries such as Java applets, Microsoft Silverlight, Macromedia Flash that were promoted for browsers to create "rich fat clients" were ultimately rejected for various reasons. The plugins had performance problems, security problems, browser crashes, etc.

Java applets was positioned by Sun & Netscape to be the "serious professional" language. Javascript was intended to be the "toy" language.

In 1999, Microsoft added XMLHttpRequest() to IE's Javascript engine to enable Outlook-for-web email that acted dynamically like Outlook-on-desktop without page refreshes. Other browsers copied that. (We described the early "web apps" with jargon such as "DHTML" DynamicHTML and "AJAX".) In 2004, Google further proved out Javascript capabilities for "rich interactive clients" with Gmail and Google Maps. Smoothly drag map tiles around and zooming in and out without Macromedia Flash. Even without any deliberate coordinated agenda, the industry collectively begins to turn Javascript from a toy language into the dominant language for all serious web apps. Javascript now had huge momentum. A language runtime being built into the browser without a standard library like Javascript was prioritized by the industry more than the other options like plugins that had a bigger "batteries included" library. This overwhelming industry preference for Javascript happened before Node.js for server-side apps in 2009 and before Steve Jobs supposedly killed Flash in 2010.

The situation today of Node.js devs using npm to download "leftpad()" and a hundred other dependencies to "fill in the gaps" of basic functionality comes from the history of Javascript's adoption.

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.

There's even worse language language for this. It's absolutely essential for an modern e-commerce, but has no official standard or spec, many thousands of libraries but they're mostly poorly maintained and geoblocked. The language itself is just a hodge podge of other languages that were popular in the past, and as a result it's worse than Perl for having too many ways to do any single thing. The major dialects may be theoretically compatible, but in practice there's usually friction when you try to mix them.

[Ok that's enough, ed.]

Since I'm here, one of my standard interview questions when I'm hiring is "how would you convert a Gregorian date to a Julian date?" (and I make clear there's no penalty for not knowing those terms, and explain them if needed.)

What I'm looking for is "there has to be a library function for that; I would look it up".

With a lot of motivation, grit, coffee and reinventing the wheel every couple of weeks.

An interesting related question could be: Why did all languages with standard libraries fail to become the lingua franca of the Web against JavaScript?

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.

It's called a web because of how it's held together.

If your local timezone is GMT>=0, then you wont see it. A special form of a Heisenbug that you only see easily when located in the Americas, while when in Europe/Africa/Asia it is invisible unless you switch your local time zone to any GMT-X value.

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.

Even more fun when that includes date or time ranges; I've literally had to paste Swedish-style dates into Claude to help me parse what the intended reading is.

I guess some people just want to see the world burn.

-20.6

Being able to does not mean that you should

Not 28/5 '25?

Best I've seen is from the venerable Jon Skeet: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...

The best advice is unfortunately to not use a generalized practice. E.g. never "just use UTC". Use UTC when it makes sense.

- Understand the semantic difference between a timestamp (absolute time) and clock/calendar time (relative time). Understand which one your use case uses. Don't use one to store the other.

- If the use case calls for a relative time, do not manually construct or edit the date. Use your platforms date-creation/modification APIs, no matter how unnecessary they seem.

- Understand what is inside your platform's date types at rest. Understand which of your platform's date APIs pull in environmental information (time/tz/locale), as opposed to only using the arguments you pass it. Understand that your platform's 'print/stringify' function may be one of those aforementioned functions. Misunderstanding this often leads people to say inaccurate things. E.g. say your platform has a Date object that stores an epoch-based timestamp. People may say "the Date object is always in UTC", when really the Date object has no time offset, which is not the same thing.

- Understand that if you pass a date around platforms, it might accidentally be reserialized into the same absolute time, but a different relative time.

- Understand that there is a hierarchy of use cases, where each one has more complex requirements:

1. "Create/modify" timestamps; egg timers. (absolute time)

2. Alarm clocks (same clock time always).

3. One-time calendar events (has an explicit, static tz; same clock time if the user changes its day or time zone; different clock time if the user's time offset changes)

4. Recurring calendar events (same as above, except don't change the clock time if the user's time offset changed due to DST, as opposed to a geographic change)

5. Recurring calendar event with multiple participants (same as above, just remember that the attached tz is based on the creator, so the clock time will shift during DST for participants in a place without matching DST rules).

Note that a lot of platforms nowadays have built-in or 3rd party packages that automatically handle a lot of the rules in the above use cases.

Finally, understand that all those little weird things about dates (weird time zones, weird formatting conventions, legislative time zone changes, retroactive legislative time zone changes, leap days, leap seconds, times that don't exist), are good to know, but they will mostly be accounted for by the above understandings. You can get into them when you want to handle the real edge cases.

It's a good talk but it's an even better talk if you actually like JS and understand not only why those things are the way they are but also that you wouldn't ever do them in normal code.