Skip site navigation (1)Skip section navigation (2)
Date:      07 Jan 1999 08:38:45 +0200
From:      Ville-Pertti Keinonen <will@iki.fi>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        current@FreeBSD.ORG
Subject:   Re: Y2K, Y 2038?
Message-ID:  <86u2y3lh8q.fsf@not.oeno.com>
In-Reply-To: Matthew Dillon's message of "6 Jan 1999 01:18:55 %2B0200"
References:  <199901052243.OAA97949@apollo.backplane.com.newsgate.clinet.fi>

next in thread | previous in thread | raw e-mail | index | archive | help

Matthew Dillon <dillon@apollo.backplane.com> writes:

>     I would prefer NOT making *two* hacks to the time system.  We should
>     just move to 64 bit 'ltime_t' or something like that.  It is not
>     a big deal.  Then we'll have 30 years to translate the legacy time_t's
>     useage into the new ltime_t useage.

Such a change would be incompatible with other systems and nobody
would be likely to use it for new code.

It would not do any good for old code that relies on time_t for
storing arbitrary dates.  It also wouldn't help the library code, all
of the interfaces use either time_t or struct tm, and there isn't
really that much internal processing going on (struct tm has a
reasonable range).

Then there's struct timeval.  And struct stat, although it's unlikely
to be something that anyone stores as binary data in a file.

IMHO FreeBSD or any other current operating system should not rush to
provide a new API to facilitate writing date-robust code, unless such
an API is standardized (or just implemented by sufficiently many other
systems).  An internal API to allow the kernel, libraries and base
system utilities to deal with dates better would naturally be ok, but
currently one would not be very useful since the core system doesn't
generally need to deal with arbitrary dates and fixing it can easily
wait until there is a standardized API to do it.

And I don't think a standard API for reliably representing dates in
general should look much like the C time.h interfaces.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86u2y3lh8q.fsf>