In your letter dated Wed, 24 Jun 2015 08:33:14 +0200 you wrote:
Leap years and DST ladjustments have never caused us any major issues. It seems these code paths are well tested and work fine.
I seem to remember that they were not tested that well on a certain brand of mobile devices a few years back... In any case, we can abstract from time zones and DST by using UTC internally and then converting to local time in the UI. For UTC the analog approach would be to keep time in TAI internally and convert to UTC when required. There is however a big problem with that. UTC as a time scale is not predictable. There is no way of computing the number of seconds between 2000-01-01 00:00 and 2100-01-01 00:00 because that value is undefined. The net results is that representing, say, 2020-01-01 00:00 as a TAI timestamp is impossible until about 6 months before that date. One way forward for people who for some reason feel attached to representing the rotation of the earth in civil time is to have a scheme for leap second just like leap years. For example, insert a leap second every 18 months. And then revise that scheme once a century to cope unexpect changes in the earth's rotation. (Or just get rid of them all together and move to a different time zone every 4000 years).