Guy Harris wrote:
On Dec 14, 2019, at 1:23 AM, Clive D.W. Feather <clive@davros.org> wrote:
Guy Harris said:
...the only way in which it "uses TAI" rather than using UTC is that the epoch is defined as...
No, that's not the only way.
What's the other way?
I'm guessing that the other way boils down to (however you try to represent dates and times) *not* having any leap seconds anywhere -- that is, unambiguously working in TAI everywhere, and drifting farther away from UTC every time there's a leap second.
Yes, and that's a big part of "avoiding the mess" - you don't worry about time zones *or* leap seconds.
...unless you need to convert a Bluetooth Mesh time stamp to UTC.
Right. I imagine that's a pretty big problem.
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?
The point is that, in a time stamping mechanism that stamps times with counts of seconds since an epoch, whether the count includes leap seconds is independent of whether the specification for the epoch includes the letters "T", "A", and "I" ...
There may be additional subtleties here that I'm overlooking, but to me, this discussion cuts to the heart of the whole eternal leap second imbroglio. Guy has, I think, tried to carefully decouple two aspects of the question: A. Does your time scale count leap seconds or not, and 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.) 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 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. 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. 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. 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.