On 2005-02-12, David Menendez
Aaron Denney writes:
It's one way of looking at it, but not the most insightful, IMO. The "dates" that TAI provides need bear no relationship to the times and days we're comftorable with.
No relationship? As I understand it, the only real difference between UTC and TAI the tradeoffs they make. TAI prioritzes constant durations for its units, and UTC prioritizes tracking the irregular rotation of the Earth. TAI agrees with the common definition that a minute is 60 seconds, and UTC approximates the common definition that a day corresponds to one rotation of the Earth. You can't do both unless you mess with the definition of a second, like UT1.
What I meant that any given datestamp would have no fixed means of conversion between the two. "Need bear". Currently they're offset at roughly half a minute. In the future this offset will be different.
The problem with drifting the epoch is that it complicates clock/calendar conversions for times in the past. That is, a function secondsFromEpoch :: CalendarTime -> ClockTime will return different values for the same input if it is evaluated at different times.
Not necessarily. You can remember where the jumps happened, and know what the epoch was for specific CalendarTimes and ClockTimes. This fails for old timestamps referencing the future relative when they were created, but those are broken anyways. This doesn't fix everything as around leap seconds there are two consecutive seconds with the same timestamp -- Aaron Denney -><-