Steve Summit said:
The times discussed in 5.1.4.2 Schedule Register presumably are [...] with non-leap years being either 31,536,000, 31,536,001, or 31,536,002 seconds long
I wouldn't presume that at all. If it's doing TAI, if it's not counting leap seconds, why would you presume years of other than 31,536,000 or 31,622,400 seconds?
Those ones are in local time, so have years of varying lengths (*cough* 1751 and 1752 *cough*).
Guy has, I think, tried to carefully decouple two aspects of the question:
A. Does your time scale count leap seconds or not, and
This depends on what you mean by a leap second. And that is part of the problem.
B. Does your representation use broken-down times ("calendar + clock"), or monotonic counts of seconds since an epoch?
I agree that those issues are orthogonal. (I'm also going to ignore for now the side question of whether the epoch mentioned in "B" is defined as a UTC or TAI timestamp.)
No. They look orthogonal at first glance, but they aren't.
So when Guy said "there are at least four different flavors of time stamp", I think his flavors map onto my two aspects A and B with this little truth table:
A B no b-d 1) TAI-style calendar+clock yes b-d 2) UTC-style calendar+clock no mono 4) counts of non-leap seconds since a specified epoch yes mono 3) counts of seconds since a specified epoch, with the count including leap seconds
[I'm wondering if that intended to have 3 before 4, based on the following text.] What I would have is, rather, the following: C: Does your time scale count every second exactly once? A "no" answer means that some seconds are not counted or are counted twice. D: Does your time scale: (1) use a monotonic count of seconds since some epoch (2) use a broken-down style with the seconds field always stepping from 59 to 00 at the end of the minute (3) use a broken-down style with the seconds field stepping from 58, 59, or 60 to 00 at the end of the minute, depending on the exact date-time. C yes D 1 is a count of SI seconds since the epoch. I called it a count of TAI seconds to avoid people confusing it with: C no D 1, which is Posix time_t and which some people erroneously think is a count of UTC seconds since the epoch. (It is approximately a count of UT1 seconds since the epoch, but I don't want to get into the SI versus sideral seconds debate). C yes D 2 is TAI broken-down format. C no D 2 is Posix broken-down format. C yes D 3 is UTC broken-down format. C no D 3 is, I hope, never used.
Me, I would say that (1) and (4) are completely compatible -- they're two different representations for the same underlying time scale. You can perfectly interconvert between them using the same algorithm Posix defines for time_t.
That algorithm can convert between D 1 and D 2 for either C case, so long as you don't mix them up.
When it comes to UTC, however, (2) and (3) are most definitely not compatible. Personally, I believe that (2) is the *only* way to represent UTC. I believe -- Posix time_t most assuredly notwithstanding -- that (3) is an abomination.
UTC is C yes D 3.
If you try to represent UTC using a monotonic count of seconds, you have to either (a) ignore leap seconds after all (as Posix does, but which totally contradicts those words "with the count including leap seconds" in the definition of (3)), or (b) use a kludgey and non-obvious (and non-Posix) mapping between your monotonic time and broken-down calendar+time, a mapping which always requires you to have a perfect leap second table available.
Yes. I agree.
And in fact, if you try to do (b), I believe that you are *not* really doing UTC, after all -- you are basically doing TAI (perhaps with a slightly different epoch), and misleadingly calling it UTC. You are engendering just as much confusion as the Posix time_t definition does. A monotonic count of seconds is simply not an appropriate representation for UTC. The only proper representation(s) of UTC are those that separate the date from the time, so that they can cleanly, honestly, openly, and explicitly accommodate those pesky days of other than 86400 seconds.
I think I agree with that as well. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646