TBH even when working with other languages I'd skew towards doing this, possibly because I've worked with JavaScript/TypeScript too much. It's a balance but there's a certain comfort in making constraints really explicit in code you control over blindly trusting the standard library to keep it's behaviour over the lifetime of the product.

[Small edits for clarity.]

Exactly. I would have never thought about using the Date class in this way. So the behavior is pretty much wtf and local time can get pretty complicated, but I wouldn't expect to get the right time, when passing some vague strings.

But I do dream of a alternative timeline, in where the web evolved different.

You decide on the format that makes sense for the user, you validate the input against that format, and then you map it into a native date.

If the date constructor supports the format you want, it’s only coincidence that makes that final mapping step simpler.

So, the native date constructor having weird behavior on invalid strings doesn’t really change real world code.

It can be a bit belt and suspenders doing validation of specific forms but shit happens. It's much better to catch stuff before it's persisted on the back end or on disk.

And there can also be man in the middle attacks or whatever, the efforts you do for validation depends still on your task at hand. How critical an error would be.

But even for the most trivial tasks I would never think of passing some user strings to Date and expect to get a valid value.

There are so many valid and reasonable cases where this will bite you.

"Real-world data" from CSV files or XML files or whatnot (that you don't control) and sometimes they have errors in them, and it's useful to know when instead of importing wrong data.

You do something wrong by mistake and getting wrong/confusing behaviour that you literally never want, and then you need to debug where that's coming from.

The user gives you a date, you have no idea what they entered and you want to know if that's correct.

Try that tactic with FUTURE dates.

Meet at 7pm still means meet at 7pm when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time.

And it's actually a more subtle problem. You actually need the context of the timezone in some applications. If your application is showing dinner reservations, for example, you want to display the time in the local time of the restaurant, not the local time of the user. You want to know when it's booked THERE, not where you happen to be right now. I want to know my booking is at 7pm, not 1pm because I happen to be in America right now.

So using GMT/UTC is not a panacea for all the date problems you face.

It's only a solution for dates in the past. And even then you might argue that sometimes it's worth also storing the local time of the user/thing the event happened to, or at the very least the timezone they were in when it happened in a separate field.

Many European railway timetable amd booking websites fall foul of this.

But - wouldn't this be just as horrible in Go or Rust or any other language? (Or god forbid, C?) Are there better timezone APIs in other languages than what you can find in NPM that make these problems any easier to deal with?

JS has libraries that make the problem easier too. Though you'll never find a magic library that makes all the complexity disappear, because at the end of the day, you do need to tell the computer whether you mean 7 pm on the wall clock of where the users happen to be, 7 pm on a specific date in a specific time zone, etc. and doing math between dates is inherently complex with e.g. daylight savings changes. You might end up creating a datetime that doesn't exist (which Elixir handles well).

The frequency in which time zones are changed surprised me the first time I looked it up. For a single country it's probably quite a big deal that doesn't happen too often. But internationally there are several changes each year. I think it was like 4-6 changes per year in the past decades.

Oh absolutely. But the difference between a sane api and other APIs is that a sane one will fail in a sane way, ideally telling me I’m holding it wrong.

Especially: the key at every turn is to fail hard if there is anything even slightly wrong rather than do something potentially incorrect. Many JS apis seem designed to continue at any cost which is the fundamental problem. You never really want a NaN. You don’t want to coerce strings to [whatever].