Type for Current Time Function

[Ashley Yakeley]

In article <SCF-IMC-01Mw8lODASt0001ca94 at smtphost1.microsoft.com>,
 "Simon Marlow" <simonmar at microsoft.com> wrote:

> 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