In article
I think I don't really understand the (days,ticks) representation. Could somebody explain the meaning of arithmetic on this type?
Is the ticks field supposed to be limited to a day's worth? Or a day + a leap second?
"Days" is an integer day number. "Ticks" is the amount of time since UTC midnight. It's limited to 86401 seconds. If this were picoseconds, its maximum value would be 86400999999999999 for the last picosecond in a day with a leap-second.
Can I add ticks to a time? If so, don't you need leap second info to do the normalisation? Or, if normalisation doesn't happen, you need leap second info to convert to UTC, right? The only conclusion seems to be that either you can't add ticks to a time, or you need leap second info which is what we're trying to avoid.
Perhaps I missed something... :-S
If you have two UTC times, there isn't always a way to know whether or not there was an intervening leap second, so there's no way to find out the absolute length of time between them. We don't have a source of TAI, and we don't have a leap-second table, so this is unavoidable: we simply don't have a uniform scale of time. Arithmetic on UTC times is going to ignore leap-seconds. It will be convenient for "calendrical" time however. For instance, there was a leap second at the end of 1998: 9:00:00pm, Dec 31st 1998 UTC + 5 hours UTC = 2:00:00am, Jan 1st 1999 UTC 2:00:00am, Jan 1st 1999 UTC + 5 hours UTC = 7:00:00am, Jan 1st 1999 UTC Because of the intervening leap-second, "5 hours UTC" is actually one second longer than "5 hours TAI" in the first sum, but the same in the second sum. In other words, it doesn't represent a fixed amount of time (just as "5 hours UT1" doesn't). There's also the matter of the leap second edge case as well. However, all the times are nice and clean when expressed in UTC. This is better for some applications (such as datebooks) and worse for others. How is this better than POSIX time? Mostly it isn't. The difference is that a (date,ticks) pair can represent UTC time unambiguously, whereas POSIX time cannot. -- Ashley Yakeley, Seattle WA