Date: Tue, 5 Jan 1999 00:07:28 +1100 From: Bruce Evans <bde@zeta.org.au> To: danny@hilink.com.au, phk@critter.freebsd.dk Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: Y2K Message-ID: <199901041307.AAA11382@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>However, it did raise the issue of just when the end of the epoch would
>>come. Everyone talks about 2038, but no matter how many times I ask my
>>calculator, it says that 2038 is 2^31 seconds after 1970, and 2^32 seconds
>>takes us to 2106. Why can't struct timeval contain long unsigned members
>>instead of long ints?
>
>Simple: because struct timeval (×pec) needs to be able to
>handle signed time intervals.
It doesn't really, but struct timeval has been defined as
{ long tv_sec; long tv_usec; } for a long time, so applications can
reasonably expect timevals to be able to handle signed time intervals.
OTOH, struct timespec is defined as { time_t tv_sec; long tv_nsec; },
where time_t is an arithmetic type (any integer or floating point type).
so applications that expect it to hold signed time intervals are just
broken (unless they figure out that it is an unsigned integer type and
do calculations mod 2^N). Most applications are broken, so time_t
can't simply be changed even if its size doesn't change. Changing it
to float would be a good warmup for changing it to longer than 32 bits.
This change would probably be invalid for POSIX systems, since seconds
resolution would not be possible.
Different considerations apply in the kernel. The kernel's representation
of times shouldn't be so closely coupled to the application interface.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901041307.AAA11382>