Pros: - No increase in heart attacks

- Nice fluid shift from month to month

- Minor errors less important

Cons:

- Rewriting of timezone code takes 8 years, claims over 800 lives as every programmer either quits or commits suicide after working on project for a few weeks

- The staggeringly difficult to detect under low load timestamping errors cause constant stress for distributed systems engineers, making the job among the most deadly in the world.

Re cons, we already have tzdata with all irregularities like DSTs and leap seconds built in. I believe that it wouldn’t be so hard for libraries who already use tzdata. And those who don’t, they couldn’t handle time intervals properly anyway.

What's wrong with just using NTP?

http://www.ntp.org/rfc.html

https://pypi.org/project/ntplib/

https://www.npmjs.com/package/ntp-client

https://www.nuget.org/packages/Rebex.Time

Let's take it one step farther, and have each second be 99.999% of a second from December 20 and June 20, and be 100.001% of a second from June 20 to December 20. Problem solved!

Imagine having to adjust every clock in your house every single month.

Honestly my only non-internet clock doesn’t tick for few years, since I moved in and stopped it because silence. But yes, that is a valid con.

I'd do what I always do when we shift our UTC offset: mentally add or subtract to get to the real time until I finally stop being lazy.