From owner-freebsd-hackers Tue Aug 18 20:41:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA10128 for freebsd-hackers-outgoing; Tue, 18 Aug 1998 20:41:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.camalott.com (mail.camalott.com [208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA10121 for ; Tue, 18 Aug 1998 20:41:44 -0700 (PDT) (envelope-from joelh@gnu.org) Received: from detlev.UUCP (tex-107.camalott.com [208.229.74.107]) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id WAA18952; Tue, 18 Aug 1998 22:42:20 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.9.1/8.9.1) id WAA12395; Tue, 18 Aug 1998 22:40:32 -0500 (CDT) (envelope-from joelh) Date: Tue, 18 Aug 1998 22:40:32 -0500 (CDT) Message-Id: <199808190340.WAA12395@detlev.UUCP> To: jbryant@unix.tfs.net CC: peter.jeremy@auss2.alcatel.com.au, freebsd-hackers@FreeBSD.ORG In-reply-to: <199808190235.VAA12287@unix.tfs.net> (message from Jim Bryant on Tue, 18 Aug 1998 21:35:36 -0500 (CDT)) Subject: Re: proposal to not change time_t From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199808190235.VAA12287@unix.tfs.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > actually it isn't that it would be hard to do in one fell swoop, it's > that hundreds of thousands of user apps would also break from this > kind of fundamental change. if you work at alcatel, you no doubt > understand how much of a pain a fell-swoop approach to time related > problems really is dealing with y2k issues. Then there is the idea that I think most Unixers have had. Are there any standards which define time_t as a 32-bit value? If so, then changing it would be a mistake anyway. If not, then consider the following more natural transition: I suspect in the next 40 years, most of us are likely to move to a 64-bit machine. At that time, we will have to recompile everything anyway, and it will be a good time to go to 64-bit time_t's. I expect that it would be a very natural transition, and won't break machines which dump time_t's into int's (lots of them, I expect), etc, etc. My biggest concerns are the filesystem, and network protocols which define a 32-bit time value. What was the idea with using the reserved bits for ns precision anyway? Can we dike it back out? > ask your neighbor about y2k, watch how paranoid he gets. the general > public is getting quietly paranoid about the y2k problem. Quietly? I hear about it constantly. I presently make the joke with users about their mousepads not being y2k compliant. I think most of them realize it's a joke... > we have 40 years to solve the time_t problem, let's do it now, but we > don't have to do it in one fell swoop. fundamental change will always > be met with opposition. Since there is going to be one fell swoop fairly soon here, I'm not that concerned about it. > i'm just surprised the csrg didn't do this. I would assume that they had the same general feeling as I did. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message