UTCTime cannot represent leap seconds

[liyang]

UTCTime is represented as a NominalDiffTime since MJD epoch.

This is problematic since we now cannot distinguish between leap seconds and the following second that belongs to the next day.

[liyang]

But UTCView can. Perhaps that's okay if we make it official (and rename it to something sensible, and fix Data.Thyme.Clock.TAI to accept it instead of UTCTime.) I'd like to know if/how people actually deal with leap seconds before making changes to the interface though.

In any case, I'm not aware of any common OS interface that allows one to query for the absolute time (TAI) that doesn't involve working backwards from a UTC time communicated over NTP, so we're stuck with getCurrentTime returning UTCTime for now.

There is a current proposal to abolish leap seconds and perhaps adopt a new time scale (TI?). The vote is due in 2015, unless it ends up being postponed again.

[ygale]

In November 2015 the ITU decided that leap seconds remain with us for the foreseeable future - at least until 2023. We should fix this now.

I think the ideas of @liyang to resolve this are good. But in my opinion, the biggest issue here is documentation. thyme uses the name UTCTime for its most common representation of time, for compatibility with the time library. But that is confusing. This UTCTime is not actually UTC. Whatever we do or don't do with the types and functions, we must make that very clear to users, and make it very clear how to use actual UTC in the thyme library when that is needed.

[llelf]

Just found out about this. This is a major issue, could we add a little info at least to Data.Thyme.Time / front haddock page, where people are looking first?

Could it be fixed by storing time modulo 86401 instead of 86400?