> Similarly, most programming languages have support for datetimes with time zones
They do, but in many languages they're easy to misuse, and I think this is an underappreciated part of the problem. I'd even argue that timezones really aren't that hard, they're hard when you use the wrong abstractions or try to tack them on as an afterthought. Ultimately there's a big lookup table that someone else manages for you (the Olsen database) that gives the current definitions of timezones and how they relate to UTC at various times of the year due to daylight savings changes. Given a local wall-clock time and a timezone name you can use this to unambiguously get the global instant in time it corresponds to.
But a lot of libraries let you ignore or mix up these underlying types, or implicitly convert between them in a way that you may not realize is happening. The biggest problem I've seen by far is that a timezone like America/Los_Angeles is not the same as an offset like -07:00 or a named offset like PDT (the latter is the most confusing and really just needs to stop being used. It has the definition of a static offset in that it means 7 hours behind UTC, but also corresponds to a place which is sometimes on PDT and sometimes PST, and also is usually referred to as just a timezone with nothing to distinguish it from timezones from the Olson database like America/Los_Angeles. And I think it also has a name collision with a timezone in Asia).
As an example of the problems this can cause, say you start with a time like 0:00 March 11 2018 in America/Los_Angeles. If you call the "to_iso861" method in any given time library you may or may not be implicitly converting the timezone to an offset as it'll return "-07:00" or maybe PST (ISO8601 doesn't have anything to say about what a timezone should be, so these are all valid). But now when you parse that again and add 4 hours to it, you'll still have a time with -7 hour offset even though the place you were originally referring to has changed and now has a -8 hour offset.
The javascript Date type is notoriously bad on its own as well, since it implicitly converts everything to the browser's local timezone offset. And moment isn't a whole lot better, the timezone support is tacked on as a separate library and it will happily let you mix up offsets and timezones as well, or let you go back and forth to a Date object which can have that same implicit conversion problem.
The only library I've seen that actually requires you to treat these concepts separately is Joda, which has port as js-joda. The syntax can be a little confusing and the js port is missing good builtin support for locale-aware formatting though, but those are all minor annoyances and well worth it for the better abstractions it gives you. The good news is there's a new builtin time library on the horizon for JS as well which seems to be borrowing from both joda and moment, as well as browser support for Olsen timezones and locale-aware time formatting, so I'm hopeful it will be easier to just "do the right thing" by default in the not too distant future.