ashley at semantic.org
Mon May 12 05:15:09 EDT 2008
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 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.
More information about the Libraries