Social issues aside, the software perspective of keeping up with DST is very costly. Every time any government entity anywhere on Earth changes its mind about what zone they're in and when, the IANA needs to reissue the TZDB. Then every OS and platform vendor needs to patch up to a new TZDB. Just for laughs, Java seems to have its own TZDB so in general your OS and application layer might disagree about zones. This i…
> the software perspective of keeping up with DST is very costly. To be clear, the software perspective is to use Unix time instead.[0] [0] https://en.wikipedia.org/wiki/Unix_time
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.