Date: Sat, 15 Aug 1998 10:23:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: grog@lemis.com (Greg Lehey) Cc: tlambert@primenet.com, mph@pobox.com, brawley@camtech.com.au, hackers@FreeBSD.ORG Subject: Re: Do we have a Y2K problem after all? (was 64-bit time_t) Message-ID: <199808151023.DAA12272@usr06.primenet.com> In-Reply-To: <19980815182033.E22238@freebie.lemis.com> from "Greg Lehey" at Aug 15, 98 06:20:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > http://www.eunet.pt/ano2000/sun/sup_sun5.htm > > A very interesting page. It doesn't have much to do with the subject > of the purpose of time_t, but it does indicate that we haven't done > all our homework relating to Y2K. Actually, you have to dig for it, but it appears that Sun does not plan to update to a 64 bit time_t yet. > How much of the changes suggested in this page should *we* emulate? The strptime() changes account for about 2/3rds of the Y2K patch releases (on the page referenced by the original article that incited this thread). FreeBSD includes this in libcompat (I think), so it's technically not as severe (except for all those Linux-heads who keep wanting it as part of libc). The other bugs may or may not exist; certianly the two digit positive roll on the year changes aren't in there, and they only put the problem off to 2069, so they aren't very satisfying -- but it does mean FreeBSD has Y2K problems. > > Negative values are (potentially) abused for dates back to December > > 13th, 1901. > > I didn't see the word "abuse" anywhere in the page. What's wrong with > using negative time_t if they're defined in the spec? They aren't in the POSIX or SOLO specification. In general, I say abuse because you either can't represent one second before Jan 1 1970 GMT, or you can, but you do it using a discontinuity (ie: it's -2, since -1 is an error indicator). Without a mandate about the discontinuity, it would probably be an error waiting to happen if, by advancing your clock monotonically from a per 1970 date through a range to a post 1970 date (ie: you would return -1, the error indicator). I think the correct thing is to mandate the discontinuity, but this may result in a one second differential based on system implementation for dates prior to 1970. I fully expect to live to see the day when 0x80000000 is one second after 0x7fffffff (in the year 2039) as the "fix" for some systems 2039 bug. Holding the next bug off another 69 years. It's interesting that we are 3/7 of the way to the 2039 bug, which was made on a similar assumption about our software not outliving our dogs... 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199808151023.DAA12272>