Data.Time questions
Dear all, I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. Before submitting a patch I want to confirm with you that they belong in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is this correct? I'm doing work on additional time coordinates of interest to e.g. astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 seconds, previously known as Terrestrial Dynamical Time or TDT) and perhaps Geocentric Coordinate Time (TCG) and others. Would you be interested in receiving patches with these rather esoteric time coordinates? If not I'll release them in a new "time-astro" package. Thanks, Bjorn Buckwalter
bjorn.buckwalter:
Dear all,
I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. Before submitting a patch I want to confirm with you that they belong in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is this correct?
I'm doing work on additional time coordinates of interest to e.g. astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 seconds, previously known as Terrestrial Dynamical Time or TDT) and perhaps Geocentric Coordinate Time (TCG) and others. Would you be interested in receiving patches with these rather esoteric time coordinates? If not I'll release them in a new "time-astro" package.
'space-time' would be a nice package name. import System.Time.Space :)
Bjorn Buckwalter wrote:
Dear all,
I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. Before submitting a patch I want to confirm with you that they belong in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is this correct?
I'm not sure if it matters, since it is instances rather than new exported symbols, and anyone using those instances must have both AbsoluteTime and ParseTime in scope already.
I'm doing work on additional time coordinates of interest to e.g. astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 seconds, previously known as Terrestrial Dynamical Time or TDT) and perhaps Geocentric Coordinate Time (TCG) and others. Would you be interested in receiving patches with these rather esoteric time coordinates? If not I'll release them in a new "time-astro" package.
Are you going to create a new type for TT? TT is isomorphic to TAI in the category of measurements. I've generally tried to avoid separate types for isomorphic measurements. That's why it's called AbsoluteTime rather than TAITime... -- Ashley Yakeley
On Sun, May 11, 2008 at 9:06 PM, Ashley Yakeley
I've implemented 'ParseTime' and 'Read' instances for 'AbsoluteTime'. Before submitting a patch I want to confirm with you that they belong in 'Data.Time.Format.Parse' as opposed to 'Data.Time.Clock.TAI'. Is this correct?
I'm not sure if it matters, since it is instances rather than new exported symbols, and anyone using those instances must have both AbsoluteTime and ParseTime in scope already.
True for the 'ParseTime' instance but not necessarily so for the 'Read' instance. I recall being rather confused at first that 'UTCTime' and its 'Show' and 'Read' instances were in three different modules, but perhaps it has to be that was due to dependencies. This doesn't seem to be the case with 'AbsoluteTime' so since you don't seems to have any preference I'll put them all in 'Data.Time.Clock.TAI'.
I'm doing work on additional time coordinates of interest to e.g. astrodynamicists. In particular Terrestrial Time (TT = TAI + 32.184 seconds, previously known as Terrestrial Dynamical Time or TDT) and perhaps Geocentric Coordinate Time (TCG) and others. Would you be interested in receiving patches with these rather esoteric time coordinates? If not I'll release them in a new "time-astro" package.
Are you going to create a new type for TT?
TT is isomorphic to TAI in the category of measurements. I've generally tried to avoid separate types for isomorphic measurements. That's why it's called AbsoluteTime rather than TAITime...
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... Thanks, Bjorn
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
On Mon, May 12, 2008 at 5:15 AM, Ashley Yakeley
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.
We could perhaps use a phantom type: data AbsTime a = MkAbsTime {unAbsTime :: DiffTime} deriving (Eq,Ord) data TAI = TAI data TT = TT ... type TAITime = AbsTime TAI ... This would allow using different instances for e.g. 'Show' while avoiding duplicating other code.
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
Note that for e.g. TCG the length of a second is "Scaled" w.r.t a TT seconds by dTT/dTCG = 1 − LG. Do you propose such information be included in the TimeScale?
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.
With the ideas above it seems we are straying further and further from the brute-force implementation I was originally envisioning for TT. I'll try to explore the design space... let me know if you have any more ideas or insights. Thanks, Bjorn
On Mon, 2008-05-12 at 02:15 -0700, I wrote:
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?
Perhaps we shouldn't at all. This is what Steve Allen has to say: http://www.ucolick.org/~sla/leapsecs/timescales.html "The forms of dynamical, atomic, and coordinate time above are not based on earth rotation. They have no connection with days in the traditional sense; thus they have no simple relationship with the concept of a calendar. It is important to remember that the 24-hour cycle of tags like 12:00:00 really only makes sense for earth rotation time." "To their credit, the BIPM do report TAI and TT using modified Julian date (MJD) notation. Nevertheless, it remains commonplace to use the traditional calendrical and sexagesimal notations when counting the seconds which are defined by these time scales. (Indeed, for the sake of human cognition this notational convenience is very nearly a requirement.) Unfortunately, that usage leads to even greater confusion about the meanings of time scales." "Denoting TAI with a tag in the form 1958-01-01T00:00:00, and denoting TT, TCG, or TCB with a tag in the form 1977-01-01T00:00:00 should be considered as a convenience only. They are merely counts of elapsed time where one anonymous and indistinguishable second follows another. It is very appropriate to count these forms of time using decimal notation from the epochs represented by those tags. But there is no observable event that happens cyclically at 12:00:00 for dynamical, atomic, or coordinate time -- the entire notion of such a cyclical process is contrary to their uniformly-incrementing conceptual definitions." -- Ashley Yakeley
participants (3)
-
Ashley Yakeley -
Bjorn Buckwalter -
Don Stewart