From: Peter Simons [mailto:simons@cryp.to]
Well, there _is_ an absolute notion of time, that is what TAI is. The reason why that seems to be of little use for the general public is that this absolute time scale just doesn't correspond to calendar time. There simply is no accurate mapping between TAI and the information 2043-04-01T00:00:00.
I assume that the only reason we can't establish a mapping between 2043-04-01T00:00:00 and TAI is because of the leap seconds problem. I assume we can map accurately between TAI and (say) 2001-01-01T00:00:00 (Gregorian). And I assume that we just accept that the TAI <-> UTC/Gregorian/whatever mapping cannot be accurate for times in the future. My point was that when you say "here is a time, specified as x", where x is one of TAI / UTC / Julian+TZ / Gregorian+TZ / etc, any of the x's is as good as any other (as long as the time is not in the future), and the internal representation of time could be any one of, or none of x. I think people are proposing TAI as an internal representation, but it's not necessary, and I'm wondering if it's even desirable. What are the limits on a 64bit TAI implementation? 64 bits gives you (signed integers): +/- 9223372036854775807: Assuming milliseconds (is this reasonable?): 922337203685477.5807 secs ~= 106751991167 days ~= 292471208 years OK, that seems plenty... ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
Bayley, Alistair wrote:
What are the limits on a 64bit TAI implementation? 64 bits gives you (signed integers): +/- 9223372036854775807:
Assuming milliseconds (is this reasonable?): 922337203685477.5807 secs ~= 106751991167 days ~= 292471208 years
OK, that seems plenty...
Some one suggested picosecond resolution - however I am sure that timing cannot be accutate at that resolution, so perhaps microsecond resolution which gives: 292471 years, at the nano-second level things seem to be getting a bit short just 292 years - seems a little Y2K3 to me. Of course planning for the far future an Integer would be better - but is it fast enough? Keean.
Bayley, Alistair writes:
I assume that the only reason we can't establish a mapping between 2043-04-01T00:00:00 and TAI is because of the leap seconds problem. [...]
I am no expert either, but that's how I understood it. TAI is perfectly accurate, but all other time systems make unpredictable jumps to accommodate the changes in earth rotation speed.
My point was that when you say "here is a time, specified as x", where x is one of TAI / UTC / Julian+TZ / Gregorian+TZ / etc, any of the x's is as good as any other (as long as the time is not in the future), and the internal representation of time could be any one of, or none of x.
I think that's true, but not being able to express a date in the future is a rather serious limitation, IMHO. If you want to do that (and you do), then not all time systems are equally good. A bank, for example, can't store its financing data in TAI, because TAI knows only the difference between two points in time. Between now and some day in the future, exactly 'n' seconds will pass. If that day is in the sufficiently distant future though, your mortgage repayment won't be due on April 1st some year, but on March 31st a second before midnight. Therefore these applications really need to store _calendar time_, which would be UTC et all. You can map TAI to calendar time iff that date is in the past or in the near future. (I think leap seconds are announced at least a year before they occur or so.) That makes TAI unsuitable as an internal representation for most applications.
Assuming milliseconds (is this reasonable?):
IMHO, a good choice to store distance in time is: type TimeDiff = (Integer, Float) That would be seconds plus a fraction of a second. Most people really just need seconds, so binding it as (ts,_) will do nicely, and those that need more granularity have arbitrary precision -- theoretically. Maybe this is even better? data Timestamp = forall a. Fractional a => TS Integer a Peter
Peter Simons wrote:
A bank, for example, can't store its financing data in TAI, because TAI knows only the difference between two points in time. Between now and some day in the future, exactly 'n' seconds will pass. If that day is in the sufficiently distant future though, your mortgage repayment won't be due on April 1st some year, but on March 31st a second before midnight. Therefore these applications really need to store _calendar time_, which would be UTC et all.
But a computer cannot count calendar time unless it knows the leap-seconds in advance forever... So the computer must count in TAI. If you want to set a reminder event in the future (say an alarm to go off at a specific time), then you must convert the counted time (TAI) to localtime (in which the event would logically be stored for the reasons you gave above)...
You can map TAI to calendar time iff that date is in the past or in the near future. (I think leap seconds are announced at least a year before they occur or so.) That makes TAI unsuitable as an internal representation for most applications.
So, the computer counts time in TAI, but stores events in the calendar in which the user specified the events...
Assuming milliseconds (is this reasonable?):
IMHO, a good choice to store distance in time is:
type TimeDiff = (Integer, Float)
Floats do not give arbitrary precision... infact certain times (like 1ms exactly) may not be representable at all! Keean.
Peter Simons
You can map TAI to calendar time iff that date is in the past or in the near future. (I think leap seconds are announced at least a year before they occur or so.) That makes TAI unsuitable as an internal representation for most applications.
I think it's half a year. It was recently announced that there will be no leap second in the middle of 2005. Someone said that tsunami made the earth rotate a bit faster. The leap second system will have to be abandoned after a hundred of years or so, because the long-time trend is Earth slowing down, so there will be more and more leap seconds. There is a proposal of adding a hour at a time, not a second at a time. These events would be much more rare, so people could prepare to them in advance. Only astronomers would be upset, because the angle of Earth rotation at a given hour would drift as time passes. One reason of using UTC instead of TAI is that most computer languages and protocols use UTC or something derived from it.
IMHO, a good choice to store distance in time is:
type TimeDiff = (Integer, Float)
With Float it gives 60ns of precision at the end of each second, and more precision near the beginning of each second. With Double it's about 2e-16 s at the worse end of a second. In my language the internal representation is like Haskell's Integer, counting ticks of implementation-defined resolution (available as a constant), which is nanoseconds in the only implementation so far, but I don't want to set a limit in stone. It's rarely visible to the user though. A difference between two times is presented as a number of seconds stored in Double. So the absolute time is in fixed point (constant precision) and relative time is floating point (convenient for computation in the human-friendly unit of a second). -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
Peter Simons
I think that's true, but not being able to express a date in the future is a rather serious limitation, IMHO. If you want to do that (and you do), then not all time systems are equally good.
The flip side of the coin is of course being unable to specify time differences with certainity in the future.
A bank, for example, can't store its financing data in TAI, because TAI knows only the difference between two points in time. Between now and some day in the future, exactly 'n' seconds will pass.
I think the bank should use a system that lets it specify, in an unambigous way, days, if that's what matters. Counting seconds shouldn't be a matter of concern. So we need two systems, and if the correspondence between them (e.g. which_day_is_this :: Time -> CalendarDay) gives the wrong answer for a second for people who update their systems more rarely than once a year, well, they get their interest (or mortgage) one second late in the worst case.
Therefore these applications really need to store _calendar time_, which would be UTC et all.
I don't think UTC seconds is the right thing either, but some real calendar type. I would like to specify "the first day of each month", not intervals of x seconds, y seconds, then x seconds again...
Assuming milliseconds (is this reasonable?):
IMHO, a good choice to store distance in time is:
type TimeDiff = (Integer, Float)
It would perhaps be nice if the interface provided a way to determine the resolution of the timer -- a guarantee of a minimum value of change, I guess. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
participants (5)
-
Bayley, Alistair -
Keean Schupke -
Ketil Malde -
Marcin 'Qrczak' Kowalczyk -
Peter Simons