Re: amd64/119591: time_t on 64-bit architecture

The following reply was made to PR amd64/119591; it has been
noted by GNATS.

From: Peter Jeremy <peterjeremyoptushome.com.au>
To: IKEGAMI Akiko <gamimoonshine.s.notwork.org>
Cc: bug-followupfreebsd.org
Subject: Re: amd64/119591: [amd64] [patch] time_t on 64-bit
architecture
Date: Sun, 13 Jan 2008 07:50:31 +1100

 --VuQYccsttdhdIfIP
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 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.  There is provision
to
 separately store the century in the RTC but this code is
not
 currently active.
 
 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.
 
 --=20
 Peter Jeremy
 
 --VuQYccsttdhdIfIP
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.4 (FreeBSD)
 
 iD8DBQFHiSgX/opHv/APuIcRAvlSAJ0ToZ3alNx0ZQToWtqr1w3NszmvuwC
ferLU
 g8VCxtobSdYLszr3QO7KM9Y=
 =pnIr
 -----END PGP SIGNATURE-----
 
 --VuQYccsttdhdIfIP--
_______________________________________________
freebsd-amd64freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to
"freebsd-amd64-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-amd64freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to
"freebsd-amd64-unsubscribefreebsd.org"