
On Sep 19, 2018, at 8:52 AM, Tobias Dammers
wrote: Also, unix time may represent either actual seconds elapsed since epoch, or "logical" seconds since epoch (ignoring leap seconds, such that midnight is always a multiple of 86400 seconds).
That would be a violation of the specification:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_...
Ah yes, you are right. Problem is, while Unix systems to day use Unix time this way, not all other software systems do, or they may assume that "current unix timestamp - some unix timestamp in the past = exact number of seconds elapsed between timestamps". Which doesn't hold in the presence of leap seconds, no matter how you implement them. In other words, people use Unix timestamps (both the word and actual implementations) sloppily.
That may be so, but Haskell's libraries should not cater to broken implementations. UNIX epoch time is the time elapsed since 19700101T00:00:00+0000 - number of leap seconds added since 19700101T00:00:00+0000. In principle this means that the epoch time repeats during the leap second. In practice smearing is the better approach taken by many systems with the clock remaining monotone, but briefly running more slowly (for added leap seconds). So you're not guaranteed precise synchronization with any particular clock, but there is a deterministic conversion from epoch time to local time that does not need to concern itself with leap seconds. This conversion will never produce a 60th second, but could produce a 59th second that never existed if there are ever negative leap seconds. -- Viktor.