I think the landscape has shifted since the US rules were last changed in 2007. It was awful for pretty much everything that needed to be timezone aware and not just show some local time to a user.

Dates & times were not yet even part of standard C++ (some support started in C++11). Boost got your part of the way there, but it's IANA timezone db support was thin. (It could handle current timezones, but not historical or future). I think MS even support IANA timezone db support on Windows somewhere. Windows' ability to handle historical timezone changes was also pretty limited, and the actually history provided was pretty slim.

While I have no doubt should the DST change be made permanent will cause all sorts of issues with software (I mean, there's plenty of software, especially in embedded that still doesn't take into account the 2007 change), I personally welcome the end of a twice yearly switch. Which direction, I don't really care. I just want the switching to end.

It's probably because Java promises "write once, run anywhere". If you rely on the system timezone tables, you might have a different set of timezones available from one system to another or the rules for the same timezone might differ. And then code would behave differently on different operating systems.

If instead you ship timezone tables with the Java Runtime Environment, then you can promise that (by default) the code will behave the same.

It sucks that it creates extra maintenance burden (and lurking problems people may not be aware of), but that's the price you pay for decoupling.

Yeah, when I read about the Java behavior I figured it was to get cross-platform consistency. All that I can say is that I concluded that the opposite approach (applications should be written to handle what the system tables provide through a shim API like Qt provides) makes more sense. I noticed this recently when I had to install some CA certs into my JRE when a java app didn't use the system ones.