- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: M. Warner Losh <imp_at_BSDIMP.COM>

Date: Tue, 26 Dec 2006 10:10:56 -0700 (MST)

In message: <20061226124029.GA3185_at_fysh.org>

Zefram <zefram_at_fysh.org> writes:

: M. Warner Losh wrote:

: >Actually, the real answer is domain specific. There are many things

: >that don't really care (when do I need to make the next 20 house

: >payments, off by one second just doesn't matter at all since

: >transcations are batched on a daily basis a few days early).

:

: In that case you don't really want a TAI<->UTC conversion. You want

: an estimate of TAI<->UT1. Possibly you'd prefer an exact TAI<->UTC

: conversion but want to fall back on the planetary rotation estimate in

: the event that UTC isn't defined that far yet. The point is that you're

: asking a different question from the one that elicits "I don't know".

Well, if I compute an interval, using UTC times, then I can go back

several decates before the results start to be suspect. Going

forward, you can get up to almost 12 months error free at some times

of the year, and a little over 6 months error free (assuming

instantaneous distribution of circular C). But going out a year

you'll have at least one leap second opportunity. Going out 2 years

gives you 3, etc. This allows one to compute these long intervals

with only a small error. If I was to compute the number of seconds

between Jan 1, 2007 0:0:0 and Dec 31, 2008 23:59:50, the answer is

63071990 or 63071991 or 63071992. We have no way of knowing today how

many seconds are in that interval. We do know the answer is one of

the above. The error in not knowing is tiny, about a 6 parts in 10^7.

Large enough to matter for some things, not large enough to matter for

others.

There's been little work on having variable precision math of this

nature where the computation depends on the numbers involved and a set

of rules. The precision work for floating point does come closest,

because there has been a lot of effort paid to analyzing the different

sources of error, but there's little work that's been done on

computing the error in parallel to the actual computation, wrapping

that up into convenient data structures and allowing the programmer to

test the results for an acceptle error (or rather in this case

uncertainty).

In all the high precision time work I've done, the biggest, most

overriding problem has been: What's the leap second value for the

immediate past (< 1 day) or near future (< 1 month). Very little

matters outside of those parameters. UTC time is important for IRIG

(and other time codes), UI display, and atomic clock coorinated

measurements (more generally, any coordinated event), but little

else. Some time scale that one can use to pace the system, or to make

measurements against is needed, but TAI or TAI-like timescales will

fit the bill. The hard part is when you need to convert from one to

the other of the time scales and a realization of the limits to doing

that.

So the answer to my above question isn't "I don't know" but rather

63071991 +- 1 given the current leap second practices. It would take

a lot longer than a year to notice different behavior in rotations and

change the rules, but factoring that in would be a crap shoot at best.

The important thing to realize also in constructing time libraries is

that I can have a TAI time in the future that doesn't have a

corresponding UTC time now, but will have one the closer we get to it.

And vice versa. I can have a UTC time (say 23:59:50 Dec 31, 2008)

that has no TAI time associated with it yet, but will at some point in

the future before that time.

: >Writing a library that copes with both types of users can be

: >problematical at best...

:

: I think a different library is required. One is about atomic timekeeping,

: the other is about astronomy.

Well, one is about atomic timekeeping. The other is the civil

approximation of astronomy, since a purely astronomical answer depends

on exactly where you are, seasonal variations, etc.

Warner

Received on Tue Dec 26 2006 - 09:13:31 PST

Date: Tue, 26 Dec 2006 10:10:56 -0700 (MST)

In message: <20061226124029.GA3185_at_fysh.org>

Zefram <zefram_at_fysh.org> writes:

: M. Warner Losh wrote:

: >Actually, the real answer is domain specific. There are many things

: >that don't really care (when do I need to make the next 20 house

: >payments, off by one second just doesn't matter at all since

: >transcations are batched on a daily basis a few days early).

:

: In that case you don't really want a TAI<->UTC conversion. You want

: an estimate of TAI<->UT1. Possibly you'd prefer an exact TAI<->UTC

: conversion but want to fall back on the planetary rotation estimate in

: the event that UTC isn't defined that far yet. The point is that you're

: asking a different question from the one that elicits "I don't know".

Well, if I compute an interval, using UTC times, then I can go back

several decates before the results start to be suspect. Going

forward, you can get up to almost 12 months error free at some times

of the year, and a little over 6 months error free (assuming

instantaneous distribution of circular C). But going out a year

you'll have at least one leap second opportunity. Going out 2 years

gives you 3, etc. This allows one to compute these long intervals

with only a small error. If I was to compute the number of seconds

between Jan 1, 2007 0:0:0 and Dec 31, 2008 23:59:50, the answer is

63071990 or 63071991 or 63071992. We have no way of knowing today how

many seconds are in that interval. We do know the answer is one of

the above. The error in not knowing is tiny, about a 6 parts in 10^7.

Large enough to matter for some things, not large enough to matter for

others.

There's been little work on having variable precision math of this

nature where the computation depends on the numbers involved and a set

of rules. The precision work for floating point does come closest,

because there has been a lot of effort paid to analyzing the different

sources of error, but there's little work that's been done on

computing the error in parallel to the actual computation, wrapping

that up into convenient data structures and allowing the programmer to

test the results for an acceptle error (or rather in this case

uncertainty).

In all the high precision time work I've done, the biggest, most

overriding problem has been: What's the leap second value for the

immediate past (< 1 day) or near future (< 1 month). Very little

matters outside of those parameters. UTC time is important for IRIG

(and other time codes), UI display, and atomic clock coorinated

measurements (more generally, any coordinated event), but little

else. Some time scale that one can use to pace the system, or to make

measurements against is needed, but TAI or TAI-like timescales will

fit the bill. The hard part is when you need to convert from one to

the other of the time scales and a realization of the limits to doing

that.

So the answer to my above question isn't "I don't know" but rather

63071991 +- 1 given the current leap second practices. It would take

a lot longer than a year to notice different behavior in rotations and

change the rules, but factoring that in would be a crap shoot at best.

The important thing to realize also in constructing time libraries is

that I can have a TAI time in the future that doesn't have a

corresponding UTC time now, but will have one the closer we get to it.

And vice versa. I can have a UTC time (say 23:59:50 Dec 31, 2008)

that has no TAI time associated with it yet, but will at some point in

the future before that time.

: >Writing a library that copes with both types of users can be

: >problematical at best...

:

: I think a different library is required. One is about atomic timekeeping,

: the other is about astronomy.

Well, one is about atomic timekeeping. The other is the civil

approximation of astronomy, since a purely astronomical answer depends

on exactly where you are, seasonal variations, etc.

Warner

Received on Tue Dec 26 2006 - 09:13:31 PST

*
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT
*