Date: Fri, 26 Oct 2001 17:38:29 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Dag-Erling Smorgrav <des@ofug.org>, Bakul Shah <bakul@bitblocks.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <200110270038.f9R0cT442082@apollo.backplane.com> References: <200110270013.f9R0DCv05573@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Much of this discussion leans this way.
:
:Just think about all this for a second, folks.
:
:We have about twenty years before this is a real problem.
:
:We have about twenty years worth of real work that needs to be done.
:
:So why don't we just put the whole, stupid time_t issue back at the
:bottom of the list, and get on with any of the hundreds of much more
:important issues that need to be dealt with, ok?
:
:And before anyone gets their knickers in a knot, remember this; all of
:the system time values (time_t, timeval, timespec) are meant to
:represent possible values of "now". Until "now" starts to blow them
:out, we have much bigger fish to fry.
:
: = Mike
Actually not quite true. We had to spend two weeks writing date/time
routines because the standard UNIX time_t routines couldn't go past
2038. The time_t limitations are creating problems *NOW*. It messes
up simulations, forward looking views, contracts that start now and
end after 2038, astronomical programs, etc etc etc. Some of the turnkey
software I wrote 20 years ago is *still* *being* *used* today.
We don't have 36 years to implement this, it's a problem that needs to
be solved now.
time_t's problem is similar to off_t's problem... it's best to get the
pain over with *NOW* rather then later. Then it's there when you need it.
-
It seems we have enough of a concensus for someone to actually start
doing this in -current. I went through the syscalls and these are the
ones we would have to roll to maintain basic binary compatibility.
stat (stat)
fstat (stat)
lstat (stat)
fhstat (stat)
select (timeval)
gettimeofday (timeval)
settimeofday (timeval)
utimes (timeval)
adjtime (timeval)
futimes (timeval)
lutimes (timeval)
clock_gettime (timespec)
clock_settime (timespec)
clock_getres (timespec)
nanosleep (timespec)
aio_suspend (timespec)
thr_sleep (timespec)
sched_rr_get_interval (timespec)
aio_waitcomplete (timespec)
kevent (timespec)
ntp_adjtime (timex)
Is anyone game for this project? I could probably do the all the
necessary kernel work in a day but we would need a general audit of
the rest of the source tree to cleanup everything else and make
sure the time conversion routines still work.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110270038.f9R0cT442082>