Not really.

Most machines use UTC internally (with varying epoch dates to represent it). And this is absolutely great until you need to interface with meatbags, ie local time. It's not just display of time either: think about anything Cron does in localtime, eg backups or open building door locks, or send an ACH payment file; then ponder all the corner cases of DST switches. Eg do you do something twice, or never? What if you reboot somewhere in the DST switch period? etc. All these shenanigans are dictated by the TZDB.

Oh, and UTC also contains leap seconds.

I doubt anyone wants something to occur twice, but they might have an opinion on whether a 1:30am job should occur on the first 1:30am or the second 1:30am in the fall change. For the spring change, I think all jobs scheduled between 2am and 3am (a period that collapses into a moment) should ideally occur at said moment, but I can see how a smear might be more practical in many cases.

I don't recall how `cron` and other schedulers handle it, though.

Every software service I’ve worked on has had issues around DST transitions. That’s really the only programming benefit I see for getting rid of it going forward.

I worked at a big tech company for half a decade, and without fail, every year there was some kind of serious bug caused by DST.

Things either happened twice or never, it was always really painful. In any growth company, I would imagine that these things keep occurring, as people haven't hit the bugs themselves yet.

> Most machines use UTC internally

No, they rally aren't. Most machines use Posix time internally, and the fact that it doesn't reflect real-world leap seconds is a problem.

Unix time says nothing about which timezone you're in.

I think that's the point