you forgot some vital ones On Thu, Feb 03, 2005 at 02:43:50AM -0800, Ashley Yakeley wrote:

* POSIX time

Can do accurate calculations on calendar times. Can store UTC times reliably. Cannot store TAI times reliably. Broken for all leap seconds. cannot represent durations undefined before 1970, muddy definition in the future.

* TAI time with limited leap-second table

Can do accurate calculations on calendar times. Cannot store UTC times reliably. Can store TAI times reliably. Broken for leap seconds after table runs out.

can represent durations defined for all history and future

Which of these is better?

TAI is clearly superior. John -- John Meacham - ⑆repetae.net⑆john⑈

When you say "defined for all history and the future", does that mean literally what it says? It accounts for the adjustments to the Calendar through various centuries, some of which are gaps of over a month (that is, corrections to get the calendar back in the right place, by adding more than a month or skipping more than a month)? I only have one user who bitches about this (he's an archeologist, so he has a reason, although his expectation may not be as reasonable as his reason). I'm not saying this is a requirement, I'm simply asking whether TAI can really handle these situations. Seth P.S.: If anyone receives this message as HTML or as combined plain text/html, please let me know. I think I've got the problem solved as long as haskell.org is in the address, but it may not be solved for addresses in other domains (such as John's above). Thanks, the response will help me troubleshoot. My logs are indicating that something went out as plain text, but I still get complaints that they arrived as html+plain text. TIA John Meacham wrote:

you forgot some vital ones

On Thu, Feb 03, 2005 at 02:43:50AM -0800, Ashley Yakeley wrote:

...

* POSIX time

Can do accurate calculations on calendar times. Can store UTC times reliably. Cannot store TAI times reliably. Broken for all leap seconds.

cannot represent durations undefined before 1970, muddy definition in the future.

...

* TAI time with limited leap-second table

Can do accurate calculations on calendar times. Cannot store UTC times reliably. Can store TAI times reliably. Broken for leap seconds after table runs out.

can represent durations defined for all history and future

...

Which of these is better?

TAI is clearly superior. John

Ketil Malde writes:

Seth Kurtzberg writes:

...

When you say [TAI is] "defined for all history and the future", does that mean literally what it says?

Well, as it is only a clock (counting SI seconds), it is unambigously defined. It is not a calendar, so you need a separate calendar to name days and years for you, and to perform the mapping between TAI's seconds and calendar entities.

As I understand it, TAI and UTC can both be described in terms of a clock counting SI seconds. The difference is that a TAI day is always 86400 seconds long, whereas a UTC day can be 86399 - 86401 seconds, depending on which second it is. Using TAI, we can always convert a date and clock time to a count of seconds and vice-versa without any additional information. To do the same with UTC, we need a table of leap-seconds. -- David Menendez http://www.eyrie.org/~zednenem/

Ashley Yakeley wrote:

In article , David Menendez wrote:

...

As I understand it, TAI and UTC can both be described in terms of a clock counting SI seconds. The difference is that a TAI day is always 86400 seconds long, whereas a UTC day can be 86399 - 86401 seconds, depending on which second it is.

Yes.

...

Using TAI, we can always convert a date and clock time to a count of seconds and vice-versa without any additional information. To do the same with UTC, we need a table of leap-seconds.

No. Date and clock times are usually UTC or some offset (time-zone) thereof. Converting to TAI requires a table of leap-seconds.

I mentioned this before, but it may have been lost in the shuffle. GPS has a clever way of handling leap seconds even though they are not known in advance. GPS receivers properly handle leap seconds, without firmware updates, even though the specifics (when each leap second occurs) are now known in advance. The general idea is that TAI time is accompanied by a value which is the current difference between TAI and UTC. That in itself is interesting, but more interesting is the fact that it can go both forwards and backwards without a leap second table. This URL has technical information: http://tycho.usno.navy.mil/gps_faq.html The site is a bit old, but the information is still current. It indicates that leap seconds are not the only corrections that are used. The latest unit for the time library (latest I've seen in this thread) is nanoseconds. The URL explains additional corrections required to keep nanosecond time. This may well be overkill for our purposes, but it doesn't hurt to look.

Ashley Yakeley writes:

In article , David Menendez wrote:

...

Using TAI, we can always convert a date and clock time to a count of seconds and vice-versa without any additional information. To do the same with UTC, we need a table of leap-seconds.

No. Date and clock times are usually UTC or some offset (time-zone) thereof. Converting to TAI requires a table of leap-seconds.

I should have been more specific. I meant, "we can always convert a date and clock time specified in TAI to a count of seconds, and vice versa". -- David Menendez http://www.eyrie.org/~zednenem/

On 2005-02-08, John Goerzen wrote:

On 2005-02-08, David Menendez wrote:

...

As I understand it, TAI and UTC can both be described in terms of a clock counting SI seconds. The difference is that a TAI day is always 86400 seconds long, whereas a UTC day can be 86399 - 86401 seconds, depending on which second it is.

No, I believe a UTC day is also always exactly 86400 seconds long.

Incorrect.

Some seconds may be longer than others (though this happens only at Leap Second events). At least this is how it works in POSIX.

POSIX (stupidly) mandates that 86400 time_t seconds / day, yes. -- Aaron Denney -><-