Date: Tue, 18 Aug 1998 22:40:32 -0500 (CDT) From: Joel Ray Holveck <joelh@gnu.org> To: jbryant@unix.tfs.net Cc: peter.jeremy@auss2.alcatel.com.au, freebsd-hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <199808190340.WAA12395@detlev.UUCP> In-Reply-To: <199808190235.VAA12287@unix.tfs.net> (message from Jim Bryant on Tue, 18 Aug 1998 21:35:36 -0500 (CDT)) References: <199808190235.VAA12287@unix.tfs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808190340.WAA12395>