headers
Bjorn Buckwalter | 12 May 02:10
Picon

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
Permalink | Reply |
headers
Don Stewart | 12 May 02:17
Gravatar

Re: Data.Time questions

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

:)
Permalink | Reply |
headers
Ashley Yakeley | 12 May 03:06

Re: Data.Time questions

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
Permalink | Reply |
headers
Bjorn Buckwalter | 12 May 04:21
Picon

Re: Data.Time questions

On Sun, May 11, 2008 at 9:06 PM, Ashley Yakeley <ashley <at> semantic.org> 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
(Continue reading)

Permalink | Reply |
headers
Ashley Yakeley | 12 May 11:15

Re: Data.Time questions

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
(Continue reading)

Permalink | Reply |
headers
Bjorn Buckwalter | 12 May 14:13
Picon

Re: Data.Time questions

On Mon, May 12, 2008 at 5:15 AM, Ashley Yakeley <ashley <at> semantic.org> 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
>
(Continue reading)

Permalink | Reply |
headers
Ashley Yakeley | 14 May 02:30

Re: Data.Time questions

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
(Continue reading)

Permalink | Reply |

Gmane