Bjorn Buckwalter wrote:
I did already create a new type for TT. However, what you are saying makes sense too (I've been wondering about the 'AbsoluteTime' name). I'm not sure that how to best handle parsing and formatting of TT without another type though... I'll give it some thought.
Hmm, I realize I might also have to reconsider my 'ParseTime' instance for 'AbsoluteTime' before I submit that patch...
I see the problem now. TT and TAI are the same up to isomorphism, but they both can be written in YMD HMS format, with a 32.184s difference. So how to parse? So far I note the interesting property that any given String logically corresponds to at most one type: "2008-05-01": Day "05:45": TimeOfDay "UTC-7": TimeZone "2008-05-01 05:45": LocalTime "2008-05-01 05:45 UTC-7": ZonedTime I'm not sure if that really matters, especially as one would need a new union type make use of it, but we could do an "instance ParseTime AbsoluteTime" if we insist on virtual time-zone strings: "2008-01-01 00:00:00 TAI": AbsoluteTime "2008-01-01 00:00:32.184 TT": AbsoluteTime "2007-12-31 23:59:41 GPS": AbsoluteTime I'm not sure what to do about FormatTime, though. Another approach is to consider the TAI, TT, GPS time-scales as a parallel system of "zones". So we currently have data ZonedTime = ZonedTime LocalTime TimeZone utcToZonedTime :: TimeZone -> UTCTime -> ZonedTime zonedTimeToUTC :: ZonedTime -> UTCTime We could add something like data ScaledTime = ScaledTime LocalTime TimeScale absoluteToScaledTime :: TimeScale -> AbsoluteTime -> ScaledTime scaledTimeToAbsolute :: ScaledTime -> AbsoluteTime This would then give us "2008-01-01 00:00:00 TAI": ScaledTime "2008-01-01 00:00:32.184 TT": ScaledTime "2007-12-31 23:59:41 GPS": ScaledTime This would belong in the "specialist" module Data.Time.Clock.TAI, which isn't included in Data.Time, so it shouldn't bother ordinary users of time. -- Ashley Yakeley