Date: Tue, 18 Aug 1998 21:09:59 -0500 (CDT) From: Jim Bryant <jbryant@unix.tfs.net> To: tlambert@primenet.com (Terry Lambert) Cc: freebsd-hackers@FreeBSD.ORG, jkh@time.cdrom.com Subject: Re: proposal to not change time_t Message-ID: <199808190209.VAA12243@unix.tfs.net> In-Reply-To: <199808182040.NAA28432@usr06.primenet.com> from Terry Lambert at "Aug 18, 98 08:40:15 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
In reply: > > i am making a proposal here to not change time_t. > > > > what i would like to propose here is to create alternate, look-alike > > functions. > > [ ... ] > > > it would be nice to be the first major unix to actually claim immunity > > to the 2039 flaw. bsd has a illustrious history of setting the > > standard. let's do it again. > > How do you propose to deal with the fact that the file timestamp > for FFS is a 32 bit value, and the spare fields that were intended > to be used to resolve the 2039 bug have been stolen to store > nanoseconds? > > Ie: how do you plan to deal with disk files created after 2039? terry: simple. as i have been told in the past, i must remind you. if you can't handle change, then don't run -current. doing alternate similar time structures and having identical functions with different names and arg sizeof is only a first, but necessary step on the path to doing this. there are a lot of things tied to a int32 time_t, so the preliminary work must be done, so as not to create a bigger kludge than it should take. this is a intermediate step so that filesystems can be developed, so that standard utilities and programs can be migrated with as little pain as possible. and so that developers and end-users can start having time-issue-free user data immediately. when a decision is made for real migration, #define's can be used as an interim kludge to port EXISTING time_t code without code changes. conversion utilities would be simple. time_t cannot, as some i have seen suggesting, be changed ad-hoc. with your experience, i would think you would recognize this in my posting. the freebsd user base may not be that big compared to others, but it is still a user base. if we don't set the standard now, linux will, or maybe netbsd... the point is to set the standard by which all others are measured. it's important to solve the problem now, while so much attention is being focused on the y2k thing, rather than merely waiting until 2037 or 2038 to do anything about it. face it terry, not many of us will still be around to cash in on that like the old-timers are on the y2k issue that they caused. honestly, i know you are proactive in some of your ideas, so let's focus on what must be done to solve the problem before the rest of the unix industry even thinks about it. face it, we do not have the installed base of say linux, and i'll lay odds that if we move now, we can beat them to the punch for that very reason. the commercial interests are already planning for a big waste of money again when the time_t deadline gets close. it would be poetic to create the standard nearly fourty years before they are planning to do anything about it. think of all the productivity that would not be lost, and all of the money not being wasted on something that has the momentum to be fixed right now. now back on the original subject. now that i have thought about it, the "q_" would be a pain in the ass to type making it unpopular with most developers. a better way would be like: typedef long long int64; typedef int64 time64_t; time39_t time64(time64_t t); etc... jordan: what do you say? it's only a matter of time before ansi reconvenes a committee for c. we are actually coming up on the average time before major revisions of language standards are usually talked about anyhow. wouldn't it be neat to set the "current practice"? history shows us that ansi language committees generally follow ten to fifteen year cycles. jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ 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?199808190209.VAA12243>