On 25 Jan 2015 17:29:25 +0000, "John Levine" said:
It shares with time zones the problem that you cannot tell what the UNIX timestamp will be for a particular future time. If you want to have something happen at, say, July 2 2025 at 12:00 UTC you can guess what the timstamp for that will be, but if there's another leapsecond or two, you'll be wrong.
It shares another problem - that doing calculations across a boundary is difficult. If you have a recurring timer that pops at 23:58:30 on June 30, and you want another one in 2 minutes. do you want a timer that the next pop is at 00:00:30 - or 00:00:29? The operating system can't tell whether the desired semantic is "as close to every 120 elapsed seconds as possible" or "as close to the half-minute tick as possible". And of course doing interval math across several years where you cross multiple leap seconds is even more problematic - for some corner cases that have an endppoint nearmidnight, doing a naive "timestamp in seconds +/- 86400 * number of days" can land you on the wrong *day*, with possibly serious consequences...