From owner-freebsd-current Wed Jan 6 22:39:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA14352 for freebsd-current-outgoing; Wed, 6 Jan 1999 22:39:57 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA14337 for ; Wed, 6 Jan 1999 22:39:52 -0800 (PST) (envelope-from will@ns.oeno.com) Received: (qmail 26802 invoked by uid 1001); 7 Jan 1999 06:39:22 -0000 To: Matthew Dillon Cc: current@FreeBSD.ORG Subject: Re: Y2K, Y 2038? References: <199901052243.OAA97949@apollo.backplane.com.newsgate.clinet.fi> From: Ville-Pertti Keinonen Date: 07 Jan 1999 08:38:45 +0200 In-Reply-To: Matthew Dillon's message of "6 Jan 1999 01:18:55 +0200" Message-ID: <86u2y3lh8q.fsf@not.oeno.com> Lines: 31 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon 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