Re: [LEAPSECS] Mechanism to provide tai-utc.dat locally

From: Rob Seaman <seaman_at_noao.edu>
Date: Mon, 25 Dec 2006 23:28:05 -0700

On Dec 25, 2006, at 9:56 PM, M. Warner Losh wrote:

> Also, things in TAI time don't care either. 1 day, 1 year, 100 years
> don't matter to TAI. Periodic things that happen at a given time of
> day (UTC) are the only things that do care.

Well, champions of pure TAI consciousness might assert that all
Universal Time is aperiodic :–)

Whether any application "cares" isn't just a function of the
timescale, but of the application. It is precisely the impossibility
of mapping time-of-day to inflexible SI seconds that makes TAI (or a
putative leapsecond-less UTC) a poor choice for conveying fractional
representations of calendar dates. Any attempt to produce a better
compromise civil time scale than the current UTC should start by
characterizing the many civilian timekeeping applications and by
valuing the various economic (and scientific, cultural, legal,
historical) trade-offs.

It might be an interesting exercise to design a separate API for
representing and conveying interval time from time-of-day. Two types
of time, two APIs. Then design the minimal set of conversion
routines after understanding under what circumstances such
conversions are necessary.

Even in the easy case of strictly linear unit conversions, such as
Celsius to Fahrenheit or milliliters to fluid ounces, users only have
to convert back-and-forth under relatively rare circumstances. One
might also point out that even in these cases multiple standards
persist. For some units, e.g., parsecs and light-years, there is
some demonstrable scientific reason for using two sets of units. For
other units, for example, centimeters versus inches, there is no
reason beyond cultural and economic hysteresis. For timekeeping,
however, interval time and time-of-day are simply two entirely
separate concepts. If virtually every ruler in America conveys both
inches and centimeters, why should our clocks (time-of-day) and our
stopwatches (interval timers) be force fit to a single pseudo-standard?

Rob
Received on Mon Dec 25 2006 - 22:28:24 PST