"Eric Ulevik" <eau at fast.fujitsu.com.au> writes:
> Time is not overly complicated, but it's not as simple as most programmers
> think. The key is to use a sensible basis for measurement (eg. UTC). Perform
> all your calculations using this basis, and treat everything else as
> labelling rules (eg. local time).

Sounds good. Most of the code around here stays in GPS or TAI as long
as possible before converting to UTC, but that's because of the
FORTRAN and C programmers' prejudice for subtraction instead of method
calls. Smalltalk helps us here; Smalltalkers expect time to be an
object, not a long integer, so no one would complain were time offsets 
computed with method calls that consulted the leap second table.

A problem with UTC is historical dates. The number of seconds per year
was not measured before the 60's, and (I think) the extra seconds were
not assigned to particular days until the 70's.

If we were to keep your strategy of using a sensible basis for
measurement and treating historical calendars as labelling rules, we
could use either ephemeris time or Julian day numbers as the sensible
basis. Unfortunately, these have the problem of not being convertible
to UTC.

For me, this *is* overly complicated.  Lex has shown that a very
simple solution exists if we ignore both leap seconds and historical
dates. I suspect that we could include either one of these with a
bearable increase in complexity, but I doubt enough users would care
for either feature to justify the extra code. And I can't think of any
solution that includes both leap seconds and historical dates that is
not excessively complex. So I like Lex's solution.

But maybe someone has a bright idea for how to make leap seconds and
historical dates simple?

-- 
Stan