amd64/119591: [amd64] [patch] time_t on 64-bit architecture

[Bruce Evans]

On Sun, 13 Jan 2008, Peter Jeremy wrote:

> Whilst I agree that the existing LEAPYEAR macro can only handle
> dates between 1901 and 2099, this macro is only used to convert
> timestamps to/from the RTC - and currently that code will only
> support dates between 1970 and 2069.

Anyway, this code should be replaced by merging from the i386 version
(after fixing style bugs in that).  The i386 version used to be identical
with the amd64 versioni, but the i386 version now uses somewhat
over-engineered generic code (kern/subr_clock.c) that has different
problems in this area: It rejects years > 2037 and is broken for years
before 1970 or 1906 (at least with 32-bit time_t's), but its leapyear()
function pretends to support the much larger range of 32-bit ints which
it cannot possibly support in full.  There has to be a range check for
the limited range that can be supported, and it may as well be for
1901-2099 or 1906-2037 or 1970-2037 or even 2000-2037 so that everything
can be simpler.

> There is provision to
> separately store the century in the RTC but this code is not
> currently active.

Better remove it in case it is used :-).  It was negatively useful even
at the Y2K boundary since the heuristic for determining the century
works better except across > 100-year intervals which no one cares about.
i386 has lost the heuristic so it can't even go back to 1999.

> Note that the code to write the time back to the RTC currently
> steps year-by-year and is therefore also needs a rethink before
> the range is massively increased.

inittodr() also loops on the year.  So does clock_ct_to_ts().  This is
a good method for a small range of years.

Bruce