On 03 February 2005 02:54, Ashley Yakeley wrote:
* Should there be a TAI type separate from a POSIX time type that the system clock would return?
My preference is yes. If necessary we could create a third module for TAI time and explicit leap-second handling, which will keep them out of the way for most people. Separate types is more complication, but the alternatives have their own issues:
http://www.haskell.org//pipermail/libraries/2005-February/003049.html I don't think we should have a type for POSIX time. What does it buy you? POSIX time is a broken notion that shouldn't be visible in our library interface. Suppose we just have a TAI time type, plus various calendar types. What goes wrong? Well, you can't accurately convert some TAI times into calendar times and vice versa, in particular all times more than 6 months ahead of the leap second table. Too bad. You can still do accurate calculations on calendar times in the future, and that's what matters. The most common conversion between TAI & calendar time is going to be for the current time, and that will be correct as long as we have an up to date leap second table. Even if we don't have an up to date leap second table, we can still convert from system clock-->TAI-->calendar time, because the leap second calculations cancel out (for a POSIX system clock).
* Should we include a (days,ticks) UTC type separate from the POSIX time type?
I have two reasons for wanting this. Firstly, correctness: the POSIX time type cannot represent leap seconds, whereas this can. Secondly, this holds the result of a useful function that splits POSIX time into the simplest possible date and time parts, which can then be used for converting to various internationalised calendars.
I don't think we need this either, at lesat not in the external interface. Any calculations you can do with this type you can do on a calendar time. Cheers, Simon