Data.Time questions

[Bjorn Buckwalter-2]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Don Stewart-2]

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

:)
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Ashley Yakeley]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Bjorn Buckwalter-2]

On Sun, May 11, 2008 at 9:06 PM, Ashley Yakeley <ashley@...> wrote:
>> 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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Ashley Yakeley]

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Bjorn Buckwalter-2]

On Mon, May 12, 2008 at 5:15 AM, Ashley Yakeley <ashley@...> 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.

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Ashley Yakeley]

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


_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries