Date: Tue, 5 Jun 2001 08:33:55 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: Mark.Andrews@nominum.com Cc: peter@dataloss.net (Peter van Dijk), freebsd-stable@FreeBSD.ORG Subject: Re: time_t definition is worng Message-ID: <200106051533.IAA02947@gndrsh.dnsmgr.net> In-Reply-To: <200106050049.f550nMv72296@drugs.dv.isc.org> from "Mark.Andrews@nominum.com" at "Jun 5, 2001 10:49:22 am"
next in thread | previous in thread | raw e-mail | index | archive | help
I know this thread is long and twisting, but the point made by this person is so often overlooked I though a reimphasis by another person who was around when we (programmers) first started thinking about Y2K as a bug... > > The fix for the epoch problem is to have time64() or similar. > time_t is badly defined. It should be allowed to die. > As a developer I have to kludge around the 2038 problem today. > > You want to know what make Y2K a problem. People who were > to short sighted to see the problem early and correct it > early. 2038 in much bigger than Y2K. The sooner there is > a solution to 2038 the better. As a young programmer/hacker in the 1970's I had first hand experience with the Y2K issue while playing with long term loan payment charts, yea, we made that code use 4 digit years, and said, fine we have 20+ years to fix the other Y2k issues... well... no one really started fixing them until 1995, and most didn't start until 1998, let us learn from history and not repeat this mad crunch!!! Bite the freaking bullet and make time_t long long across all platforms NOW!! Yes, you'll have to fix ufs, and probably a lot of things that we haven't even thought of, but NOW is the time to start, not in 20 years!! -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106051533.IAA02947>