[solardev]

When I read this, the first thing that came to mind was "until you have to work with time zones". I generally enjoy working in JS, but it's such a pain point for me that I can't help but not think about it whenever I see a datetime.

It doesn't get as much mindshare as the problems with typing and frameworks and fashion trends and such, but my god, I've never seen a major, popular language with such poor support for basic time zone manipulation and storage. It is really really bad and won't be fixed until the Temporal API is stable and widely available: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[codingclaws]

What app/problem requires so much JS time zone manipulation? I have an app that's front and back-end JS, and I do all time zone stuff in Postgres.

[solardev]

It's not even anything fancy, just even simple things like calendars, date pickers, meeting schedulers, etc. Sure, you can do it all serverside, but we're talking about JS here, not any external database.

JS itself can't "keep" an original timezone in a Date() object. e.g.:

`new Date("2024-04-01T00:00:00Z").toString() `

Becomes your browser's time zone, even though the input was in Zulu/UTC. Also note that a time offset (Z or +08:00) is not the same as an IANA time zone string, and that's a one-way conversion. If you go from something like Los_Angeles to -7:00, you have no way to tell if the -7:00 is due to a daylight savings time or another locale that doesn't observe American DST. And JS doesn't store either piece of info.

If you have multiple users across different time zones trying to plan an event together, JS's date handling is super footgunny (is that a word?) and it's very easy for devs to make errors when converting datetimes back and forth from the server/DB to the app UI.

And because JS is so powerful today, there are many things that should be doable entirely clientside, but aren't easy right now. For example, relative time: wanting to make a scheduler that can search for +/- 7 days from a certain selected datetime. What is a "day"... is it 24 hours * 7? What do you do about daylight savings time boundaries? Or if you go from Feb 1 to Mar 1, is that "one month" or "28 days"?

These may seem like edge cases to you, but when it comes to datetime... really it's all edge cases :( You run into half-hour timezones, daylight savings time (which is a set of rules that vary over time even within the same country, not just a static offset per timezone and date range), cross-locale formatting, etc.

A lot of this is very doable with existing libs like Luxon, or datefns for simpler use cases, but they are fundamentally hacking around the weaknesses of the built-in Date() object with their own data structures and abstractions.

For me as a frontend dev working on ecommerce sites and dashboards, I've had to correct more datetime bugs from other JS devs (including some with decades of experience) than any other issue, including React state management. The tricky part is that a lot of the weaknesses are non-obvious, but it really is buggy and weak as heck, especially compared to many serverside languages. It's based on a very early implementation of Java's dates, which has since gotten a lot better, but JS's Date was still frozen in time.

Thankfully, most if not all of these issues will be solved with the Temporal API once it's stable... it's been like 10+ years under development, since the Moment days. Can't wait!