cvs commit: src/sys/sys _timeval.h src/sys/fs/procfs procfs_status.c src/libexec/bootpd bootpd.c src/sys/dev/acpica/Osd OsdSynch.c src/sys/dev/firewire sbp.c

[Poul-Henning Kamp]

In message <20051227.140049.73660062.imp at bsdimp.com>, "M. Warner Losh" writes:

>The chances that any of the hardware that's running FreeBSD today will
>be in service in 2020, much less 2030 or 2038 is vanishingly small.
>How many machines that were built in 1990 are still in service?  How
>many from 1980?  How many from 1970?  How many from 1967?

More than one would immediately expect I'm afraid, and more often
than not, they are in service because they are so hard to replace.

>There are good reasons to switch to a 64-bit time_t well in advance of
>the 2038 deadline.  30-year mortgage calculations will be the first
>class of things to fail.

s/will be the/will be amongst the/

>The disruption from going to 64-bit time_t
>is big, but mitigated somewhat by symbol versioning that was recently
>introduced.

This is one of those places where a forward thinking standardization
process could be a big win for UNIX.

If instead of just extending the width, one redefined the epoch at the
same time, it would be possible to make the migration much safer.

Imagine if the epoch for 64 bit time_t was set to coincide with Julian
Day zero using the rather naiive POSIX math:
	N [days] * 86400 [seconds/day]

Converting from an old time_t to the new one would entail adding an
constant offset, no big deal.

But if anybody by accident would simply extend the width of a 32bit
time_t to 64 bit, it would stick out like a sore thumb by being either
way in the past or way in the future, something that could be checked
explicitly (or implicitly by the user seeing weird timestamps).

But I'm dreaming here,  just ignore me.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.