Date: Tue, 27 Dec 2005 22:16:18 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "M. Warner Losh" <imp@bsdimp.com> Cc: trhodes@FreeBSD.org, scottl@samsco.org, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, fullermd@over-yonder.net, linimon@lonesome.com Subject: Re: 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 Message-ID: <47758.1135718178@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 27 Dec 2005 14:00:49 MST." <20051227.140049.73660062.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20051227.140049.73660062.imp@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47758.1135718178>