PROCESSING.. LX1.TXT I received the following message implying that Linux is not Year 2000 compliant. Is this true or may I tell Bruce that he is talking ~!@#$%^. > From: Bruce Ward > Subject: Re: System: Linux Year 2000 compliance > What hardware are you running Linux on? For PC's most versions of Linux > are not compliant. The kernal reads the date and time directly from the > real time clock. It does so by reading the year (2 digit not including > century) from the RTC and then adds it to 1900. So 2000 will be 00 + > 1900 which is 1900. Recent releases of Linux have a windowing technique > used in the kernal to make it accept dates as 2000. > > What are the implications for Linux users? Utilities, apps ? Another message contained the following..... > This is what get_cmos_time of/arch/i386/kernel/time.c of 2.0.32 shows: > > if ((year += 1900) < 1970) > year += 100; > > rather simple, but elegant, eh? Comments please. Regards, Alf Stockton stockton@fast.co.za www.fast.co.za/~stockton Confusion not only reigns, it pours. -- tagline 1.00 by xopy PROCESSING.. LX2.TXT In message <1.5.4.16.19971224185650.3f1f4518@pop.fast.co.za>, Chris Anderson writes: > At 08:29 1997-12-24 +0000, pobeirne@gpo.iol.ie wrote: > > >What are the implications for Linux users? Utilities, apps ? > > Excellent question (as always). Later kernels are now supporting > 64bit clocks, but the actual Y2K status of kernels 2.0.30 backwards > need to be formally established. This is what get_cmos_time of/arch/i386/kernel/time.c of 2.0.32 shows: if ((year += 1900) < 1970) year += 100; rather simple, but elegant, eh? > The problems of interpreting time_t as two digits in apps > still remains (as in any Unix). I am not a "Y2K consultant" :-)-O, but don't you worry a thing about linux's date and time functions, Linus will sort it out if it is not yet sorted :-)-O That's in fact the beauty of the Internet. > I am waiting for a new hard disk (perhaps Father Christmas will > bring one - NOT!) and plan to do testing on exactly this topic in > the New Year. My Landlord is a real Guru on Linux > so I shall try to inspan him. My sister visited from Germany and brought "toys for the boys" including a 3.5Gig drive for me :-)-O > BTW I seem to remember that there was a review of the > "Linux Disk" (Canadian?) sometime in the last couple > of years in Linux Journal. I will try to dig it up. > > The concept is good. Just install a hard drive with Linux > preinstalled and preconfigured, Boot, and away you go. The concept is BAD! (for developing countries) > I personally prefer to Install from CD, as it is a learning process > and you know what is being put where. From what I remember > of the Ad, the cost is basically that of the hard disk so it appears > to be cost effective and could well be a good startup option. > > My problem is as always getting dollars out of the country > and coughing up the exchange difference. It is cheaper for > us to import from Taiwan rather than the USA or Canada. Actually, they have relaxed the foreign exchange control regs in South Africa, they didn't have the courage yet in Namibia. But in most countries it the problem is laying your hands on foreign exchange. Then the logistics, including getting the sucker out of customs :-)-O. Expensive... It's much cheaper to order a CD Rom. CheapByte sells RedHet 4.2 and 5.0 for 1.95$US. I use 4.2 and will only upgrade when 5.2 is out because RedHat uses 5.0 users as guinea pigs :-)-O (many little bugs reported on the mailing list). Putting in a preconfigured hard disk is like flying in a foreign consultant to set the box up. We all know how much good that would do. No, I totally agree (and I do have personal experience) you must install from the CD yourself and learn as you go. There is enough assistance available on the Internet... el PROCESSING.. LX3.TXT Date: Mon, 21 Oct 1996 14:54:32 -0400 (EDT) From: "Richard A. Painter" > Date: Thu, 10 Oct 1996 16:39:58 -0700 > From: "Jon L. Pope" > Subject: Unix Question and Year 2000. > > Need help with reference. We are preparing to issue report on Y2K. In > this report, want to state that Unix is not a major issue until 2037. > Does anyone have a source for this? I have searched and unable to find > an acceptable source to quote. > > thanks and may all your systems run in 2000. > > Jon > greetings! in reply to jon's question i have included the actual calculation of the year the unix time runs out. jon states that it is 2037 but this this is not precise. the year is 2038. once the magic time arrives the time may reset to the unix birth date of 1 jan 1970 depending on the underlying hardware and implementation. all unix systems (i know of no exceptions) rely on a basic system call function called time() to obtain the time. this function returns a (signed) long integer of seconds since the epoch. the epoch is defined as the birth of unix, that is 1 jan 1970. the arithmetic follows: max seconds in a long = 2147483647 seconds = 35791394 minutes = 596523 hours = 24855 days = 68 years therefore, 68 years plus 1970 yeilds 2038. the point in time that this will happen is tue 19 jan 2038 at 03:14 and 7 sec. am gmt. please note that this accounts for the leap year days too. here is a very simple c program you can use to verify this... #include #include #include main() { time_t maxt = LONG_MAX; /* 2147483647L */ printf("The end of time as we know it is %s GMT\n", asctime(gmtime(&maxt))); } /* cc -O -o maxtime maxtime.c cc -O -o maxtime maxtime.c */ /* the output on a Data General AViiON is The end of time as we know it is Tue Jan 19 03:14:07 2038 GMT */ i welcome all questions and comments! rich painter +-------------------------------------------------------+ | Richard A. Painter painter@spectra.net | | Painter Engineering, Inc. r.painter@ieee.org | | 5800 SW 25th St. #2 | | Hollywood, FL 33023 | | | | 607.757.9778 Phone (temp) | | 607.757.0412 Manual Facsimile (temp) | | | | Systems & Software Engineering + Consulting + Audits | | Networking + Real-time Transaction Processing | | Year 2000 Solutions + UNIX + MS Windows + Security | +-------------------------------------------------------+ ****< This week, the Y2k List is sponsored by: >***********From: Eudora******* * Me... Peter de Jager... * * To UNSUBSCRIBE send a note to y2k@tor.hookup.net * * Subject line ***ADMIN***UNSUBSCRIBE * * In future, maillist status reports will be available on the Homepage * ****************************************************************************** *** Date: Tue, 22 Oct 1996 10:57:14 -0700 (PDT) From: Tracy Monaghan > Date: Thu, 10 Oct 1996 16:39:58 -0700 > From: "Jon L. Pope" > Subject: Unix Question and Year 2000. > > Need help with reference. We are preparing to issue report on Y2K. In > this report, want to state that Unix is not a major issue until 2037. > Does anyone have a source for this? I have searched and unable to find > an acceptable source to quote. > > thanks and may all your systems run in 2000. > > Jon A footnote appears in the book, _Using C on the UNIX System_, published by O'Reilly & Assoc. >From Chapter 7, "Telling Time and Timing Things": For those who care, assuming a 32-bit signed integer, UNIX will break at 03:14:08 January 19, 2038 UTC. Hope this fills your need. Cheers, Tracy * Tis true: Sr. Computer Specialist * there's magic in the web... Computing & Communications: Box 354844 * Shakespeare http://weber.u.washington.edu/~monaghan/ * Othello, Act 3, Scene 4 ****< This week, the Y2k List is sponsored by: >***********From: Eudora******* * Me... Peter de Jager... * * To UNSUBSCRIBE send a note to y2k@tor.hookup.net * * Subject line ***ADMIN***UNSUBSCRIBE * * In future, maillist status reports will be available on the Homepage * ****************************************************************************** *** Date: Tue, 5 Nov 1996 14:29:41 +0000 From: Glenn Ericson >Date: Tue, 22 Oct 1996 10:57:14 -0700 (PDT) >From: Tracy Monaghan > >> Date: Thu, 10 Oct 1996 16:39:58 -0700 >> From: "Jon L. Pope" >> Subject: Unix Question and Year 2000. >> >> Need help with reference. We are preparing to issue report on Y2K. In >> this report, want to state that Unix is not a major issue until 2037. >> Does anyone have a source for this? I have searched and unable to find >> an acceptable source to quote. >> >> thanks and may all your systems run in 2000. >> >> Jon > >A footnote appears in the book, _Using C on the UNIX System_, published by >O'Reilly & Assoc. > >>From Chapter 7, "Telling Time and Timing Things": > > For those who care, assuming a 32-bit signed integer, UNIX will break > at 03:14:08 January 19, 2038 UTC. > > > >Hope this fills your need. > >Cheers, > >Tracy * Tis true: >Sr. Computer Specialist * there's magic in the web... >Computing & Communications: Box 354844 * Shakespeare >http://weber.u.washington.edu/~monaghan/ * Othello, Act 3, Scene 4 > *************************************************************************** HOLD ON (redial) The date 2000 causes the same application problems & concerns for all regardless Unix or not. The reference you mention more likely refers to when the "C" language or UNIX system support will incurr major support problems with dates. I think it is sooner then 2038 too. Maybe someone rembers exact dates Glenn Glenn Ericson Ph. 718 898 9805 Phoenix Consulting Fx 718 446 1150 P O Box 701164 AS/400 & Year 2000- - Solutions East Elmhurst NY 11370-3164 ****< This week, the Y2k List is sponsored by: >***********From: Eudora******* * Me... Peter de Jager... * * To UNSUBSCRIBE send a note to y2k@tor.hookup.net * * Subject line ***ADMIN***UNSUBSCRIBE * * In future, maillist status reports will be available on the Homepage * ****************************************************************************** *** Date: Tue, 05 Nov 1996 06:54:30 -0500 From: George Girod >Date: Tue, 22 Oct 1996 10:57:14 -0700 (PDT) >From: Tracy Monaghan > >> Date: Thu, 10 Oct 1996 16:39:58 -0700 >> From: "Jon L. Pope" >> Subject: Unix Question and Year 2000. >> >> Need help with reference. We are preparing to issue report on Y2K. In >> this report, want to state that Unix is not a major issue until 2037. >> Does anyone have a source for this? I have searched and unable to find >> an acceptable source to quote. >> >> thanks and may all your systems run in 2000. >> >> Jon > >A footnote appears in the book, _Using C on the UNIX System_, published by >O'Reilly & Assoc. > >>From Chapter 7, "Telling Time and Timing Things": > > For those who care, assuming a 32-bit signed integer, UNIX will break > at 03:14:08 January 19, 2038 UTC. > > > >Hope this fills your need. > >Cheers, Unix itself will survive the century, but the applications may well have two-digit dates and not have the same problems as in any other environment. The younger ones among us will be veterans when 2037 arrives and nobody can say we didn't have warning! :-) ****< This week, the Y2k List is sponsored by: >***********From: Eudora******* * Me... Peter de Jager... * * To UNSUBSCRIBE send a note to y2k@tor.hookup.net * * Subject line ***ADMIN***UNSUBSCRIBE * * In future, maillist status reports will be available on the Homepage * ****************************************************************************** *** Date: Wed, 13 Nov 1996 12:43:12 -0500 From: JohnKatie3@aol.com I disagree that UNIX has no problem with year 2000. What do you mean. I am working in a UNIX/ORACLE environment with C/S applications that have all kinds of year 2000 related problems. You're probably correct in saying that the system date format does not have a problem, but there is no guarantee that your applications don't. Best regards..........John C. Scott JohnKatie3 @ aol.com ****< This week, the Y2k List is sponsored by: >***********From: Eudora******* * Me... Peter de Jager... * * To UNSUBSCRIBE send a note to y2k@tor.hookup.net * * Subject line ***ADMIN***UNSUBSCRIBE * * In future, maillist status reports will be available on the Homepage * ****************************************************************************** *** Date: Thu, 10 Oct 1996 16:39:58 -0700 From: "Jon L. Pope" Subject: Unix Question and Year 2000. Need help with reference. We are preparing to issue report on Y2K. In this report, want to state that Unix is not a major issue until 2037. Does anyone have a source for this? I have searched and unable to find an acceptable source to quote. thanks and may all your systems run in 2000. Jon ****< This week, the Y2k List is sponsored by: >****************************** * Me... Peter de Jager... * * To UNSUBSCRIBE send a note to y2k@tor.hookup.net * * Subject line ***ADMIN***UNSUBSCRIBE * * In future, maillist status reports will be available on the Homepage * ****************************************************************************** ****< This week, the Y2k List is sponsored by: >****************************** * Me... Peter de Jager... * * To UNSUBSCRIBE send a note to y2k@tor.hookup.net * * Subject line ***ADMIN***UNSUBSCRIBE * * In future, maillist status reports will be available on the Homepage * ****************************************************************************** Date: 21 Oct 96 12:31:33 EDT From: Steven Bender <75444.1351@CompuServe.COM> Steven Bender Software Engineer Sycon Instruments East Syracuse, NY Related to original message from J Pope below: >From: "Jon L. Pope" >Subject: Unix Question and Year 2000. >Need help with reference. We are preparing to issue report on Y2K. In this report, want to state that Unix is >not a major issue until 2037. Does anyone have a source for this? I have searched and unable to find an >acceptable source to quote. >thanks and may all your systems run in 2000. Jon and others, I am a software engineer and use C and MSDOS as well as real-time embedded platforms. I don't know if I am a quotable source by your standards, but I can explain the elemental truths of what you want to know. UNIX compatible time keeping (including MSDOS function libraries from Borland Turbo C compilers) uses a 32 bit signed long integer number to hold the number of seconds elapsed since Jan. 1, 1970 GMT (Greenwich Mean Time, Zulu time). The largest signed number which can be represented with this number encoding is 7FFF FFFF hex or 2,147,483,647 decimal. Dividing this quantity by 60 for minutes, 60 again for hours, 24 for days and 365.25 for years yields 68.04928 years. The last time coordinate which can be expressed as 7FFFFFFF is 2038-01-19 03:14:07 GMT. The 32 bit value for storage is only using 31 bits by being limited to signed 7FFFFFFF expression. The actual number, if unsigned, could extend an additional 68.05 years, thereby reaching into the year 2106. However, the existing math routines which are part of the UNIX time library relies on the signed representation for many of the algorithms to work properly. Therefore your answer is the current typical use of UNIX time both in representation/storage size and algorithm function is TERMINAL on 2038-1-19 depending on your time zone. With proper algorithm fixes to handle sign extension/underflow boundary conditions during manipulation, the 32 bit storage unsigned represen- tation would last until 2106. There is no way to have a specific resolution (say, seconds) and a particular dynamic range (say, 200 years, or 400 years, or 10000 years or whatever) without designing in at the beginning an adequate number of bits or character fields to accomodate it. No Free Lunches. By the way, this only relates to the internal representation and computation aspect of temporal coordinates in UNIX. Character parsing of human or computer ASCII database strings (i.e. 9/1/55 for my birthdate using American M/D/Y field ordering) would still be subject to the CENTURY truncation/ambiguity Y2K problem. Any screen output, bar code output/input, keyboard input , etc.. transactions would have very individual problems. Read as BLOW UP at turn of century anyways. Being UNIX does not protect us from the human character interface conventions of the decimal number representation for year being limited to two digits (Modulo 100). Attempts to use alpha characters to extend the 0..9 (modulo 10) limitation is a sly attempt to increase the size of the character encoding set permutations (modulo), allowing more unique encodings to be represented non-ambiguously in the same visual/printed/stored field size. I hope this sheds some light on what you need for your report. Steven Bender, Sycon Instruments. ****< This week, the Y2k List is sponsored by: >***********From: Eudora******* * Me... Peter de Jager... * * To UNSUBSCRIBE send a note to y2k@tor.hookup.net * * Subject line ***ADMIN***UNSUBSCRIBE * * In future, maillist status reports will be available on the Homepage * ****************************************************************************** *** (A copy of this message has also been posted to the following newsgroups: comp.software.year-2000) In article <32e6862e.1061974@news2.fast.co.za>, slug@fast.co.za (Chris Anderson) wrote: ....[snip] > I am considering starting a Cinderella "Ask Auntie" service to help > those with questions, so ask away, I'm Listening. --------- OK. What tools are available to scan the scripts written for the various unix shells? Also, for PERL. Regards, Are there any tools that run in a Unix environment that will analyze the Progress 4GL language? Thanks, Eric Chris, We have a major application that runs a $4 billion dollar business that has been modified extensively with many different interfaces to Mainframe, AS/400 and client server systems and we can't run the risk of just saying it is ok because Progress says so. We also don't have the development staff right now that can support the package because they are developing other systems. To compound the issue, this system is installed in Germany, Italy, and other European countries as well as ASIA and I need to spend time with the analysis. I'm not a Progress person so I don't have knowledge in Grep. I have heard of it, but that is the extent of my Progress background. Eric ______________________________ Reply Separator _________________________________ Subject: Re: Unix Tools that analyze Progress 4GL Author: slug@fast.co.za at Mailhub Date: 1/25/97 11:07 PM At 11:03 AM 1997-01-24 -0800, you wrote: >Are there any tools that run in a Unix environment that will analyze >the Progress 4GL language? > Why would you want to do this? Progress have always bragged that their dates run from 1/1/32768 BC through 12/31/32767 AD. But certainly in release 5 they never had a year/month/day format. The date fields are binary. You select the display format as a Global option. Your database definition shows which fields are dates. Change the Global and recompile. I can understand your concern if all you have is a third party encrypted system. The displays may not look nice but the logic works. Or not? is there something that I am missing? The programs are text so grep will work like a charm as a scanner. The old Varnet environment used to have a "search for keyword". I threw out Progress some time ago as being too expensive and restrictive. What has changed to cause this new concern? ------------------------------------------------------------------------ Chris Anderson email: slug@fast.co.za Y2K Cinderella Project webmaster@cinderella.co.za http://www.cinderella.co.za Striving for Year 2000 Compliance ------------------------------------------------------------------------ Do you want info on what is GPS or on what is the problem? Grayson Lynn Grayson@POBoxes.com "Inventions reached their limit long ago, and I see no hope for future development". -- Julius Frontinius, 1st century AD Dear Chris, GPS is global positioning system. The problem is well known, and has little to so with the Y2K issue. Karl -----Original Message----- From: Chris Anderson [SMTP:slug@fast.co.za] Sent: Tuesday, January 28, 1997 4:37 AM To: y2k@LEBA.NET; listmanager@zebra.co.uk; year2000@hookup.net Subject: Re: Unix 'mktime' and year 2038 markayoung@aol.com wrote: 2038 and C libraries other than Unix .. GOOD spot. Oops. Much check this... >Other magic dates: > > Year 2042 = IBM mainframe hardware clock overflows. I redid the math on the IBM clock again recently. Assuming 63 bits (ignoring the sign) and converting from microseconds to years I found that the IBM clock would not in fact overflow for +- 260,000 years. One of the reaons I advocated YYYYYYMMDD but noone took me seriously. Or is there something that I am missing? > Year 1999 = In August, 1999, the 10-bit GPS "week number" rolls over to >0. This is a new one to me. GPS? Please tell more. What about the infamous 999 days to Year 2000? The problem in the OS Tape Catalog and File expiry problem? Doesn't that qualify as a "magic Date"? Nice article. B>) ---------------------------------------------------------------- Chris Anderson email: slug@fast.co.za Y2K Cinderella Project webmaster@cinderella.co.za www.cinderella.co.za - Striving to achieve Year 2000 Compliance ---------------------------------------------------------------- Hello from Norway! Chis; I have been following the Cinderella project form january 1997, and I in fact i am one of the 84 recipients of mailings from Year 2000 SA SIG. I work as a consultant, providing solutions for Mainframes and PC`s in the nordic area, representing GMT and Alydaar (SmartCode) in this region. I am (of course) quite familiar with the possible problems in bot legacy systems on mainframe and hard/software issues on PC. A client recently asked about the unix environment, and I was not able to reply properly. I have not suceeded in finding anything on the web either. Questions: 1: Is the Unix operating environment year 2000 compliant?? 2: Do you know of a tool (or vendor) that can parse/scan Unix applications for compliance?? Regards Erik Dambo PROCESSING.. LX4.TXT > >In article , Thanh Ma (tma@encore.com) writes: >>slug@fast.co.za (Chris Anderson) writes: >> >> >>>4. Install "year2000.com" from RightTime >>> in your autoexec.bat. >> >>Won't work for Unix-base PCs. Is there source code available to port it >>to Unix ? > > Can you run Dossy-windose on top of Unix on a PC? Sort of like >running it on top of OS/2? > If you did (OB2000) would you have problems in 2000 AND 2038? > J. >>-- >>Thanh Ma >>tma@encore.com >> Linux, DOS, Windows, and OS/2 can all reside happily on one system and share FAT formatted disks. Year2000.com would not help you unless you boot from Dos On my system, I have a menu in my config.sys to choose which system to use DOS, Linux or OS/2. So I will boot DOS first, fix the date and not worry about it again. The BIOS date problem is not Operating System related it applies generically to Intel 286, 386, 486 and Pentium types and their clones.. You only have to set the date once. How you set it on 1997/12/31 23:55:00 is up to you. My suggestion is a) set 2000/01/01 in the BIOS or b) via a date command BEFORE midnight to disallow the tickover from ever happening. After midnight adjust the time. Unix systems have a date command. For System V ( e.g. linux or SCO) it is "date MMddhhmm[CC][YY]" . Obviously you have to be Superuser. So: shortly before midnight, issue the command: date 010100012000 If you want to get smart you can use CRON to trigger the date command , this would have the same effect as Year2000.com. ---------------------------------------------------------------- Chris Anderson email: slug@fast.co.za Y2K Cinderella Project webmaster@cinderella.co.za www.cinderella.co.za - Striving to achieve Year 2000 Compliance ---------------------------------------------------------------- PROCESSING.. LX5.TXT Date: Mon, 04 Nov 1996 08:13:31 -0500 From: "XPS - Xpress Software, Inc" Much has been said about Cobol 2 digit year. What about C? For the record here are some of the easy ones: - struct tm { ... int tm_year; ----> years since 1900 ... } A common implementation is: printf("19%.2d",tm->tm_year); the correct way should have been: printf("%d",(tm->tm_year + 1900)); This is a BIIIIIIGGGGG problem around. Watch out UNIX folks. Your application is NOT (and I mean it) year 2000 compliant. As they say, C is the best language to screw up without even knowing it. The run time routine asctime() should be checked on each compiler. This routine uses the struct tm. It prints a 4 digit year but who knows how it is being created (uses the tm struct above). The C time structures (with a 32 bit integer) will expire on Jan, 18 2038. For those special (or older) applications still using 16 bit (an int it's not a 32 bit int everywhere) int's will run into trouble on 2005 (did I say MS/DOS? ha ha ha. Billy boy). A lot of special equipment uses a special implementation of MS/DOS running under a 286 or 386, some still use the good old 8086's. Watch out for those. ****< This week, the Y2k List is sponsored by: >***********From: Eudora******* * Me... Peter de Jager... * * To UNSUBSCRIBE send a note to y2k@tor.hookup.net * * Subject line ***ADMIN***UNSUBSCRIBE * * In future, maillist status reports will be available on the Homepage * ****************************************************************************** *** PROCESSING.. LX6.TXT From gedau@isa.mim.com.au Sat Jan 10 05:09:10 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: gedau@isa.mim.com.au (George Dau) Date: Sat, 10 Jan 1998 03:09:10 GMT David Lee Lambert wrote: ]Has anyone checked Linux for Year 2000 compliance? ] ]What do the vendors (RedHat, Caldera, etc.) have to say about it? ] ]What about the apps on Sunsite, like PostGreSQL? I have done some tests on a Linux box. The machine is mainly used as an X display for apps that run on other machines. It doesn't run anything much itself. It started as Slackware 1.2.13 and was hand-upgraded to 2.0.0. The hardware is an Osborne 486 DX-2/66 with 16Meg ram, Phoenix 80486 ROM BIOS PLUS Version 1.10 I set the date to Dec 1999 via the unix date command and let it roll-over, which it did no problems. I set the date to Dec 1999 in the BIOS and let it rollover to 2000 The `date` command reported Jan 01, 2000. I re-booted it and it went back to Jan 1990 (according to the bios). I set the date back to just before midnight and turned it off and let it roll-over while turned off. It booted as Jan 2000 (according to unix `date` command). I booted it again to check the cmos, it was 00:00:00 Jan 1990 again (according to the bios). I let it boot Linux and it was also 00:02:00 Jan 1990. So I have a non-compliant BIOS. I'll have to run ntpdate during the boot process to update the unix clock (or xntpd will fail and the date will be wrong). This one will roll-over fine on party night. -- ,-,_|\ George Dau, __ / * \ Unix (Solaris, DEC Unix, Linux), NT, Oracle, Internet. (OO) \_,--\_/ Home: gedau@pobox.com Work: gedau@isa.mim.com.au ( \/ ) v WWW: http://pobox.com/~gedau W--W Food for spambots: morilloruth@microjuris.com info@dproducts.be boulanger@dproducts.be caceeqi68@ma.interbroad.or.jp mwa234@hotmail.com yogiherbs@healthyherbs.com webmaster@www.brasilia.net plummer@ClipTrakker.com info2001@usa.net mramail@yahoo.com frant@mclafmall.com info@mclafmall.com earn@health.com ianc@atlantic-brands.com bulk@spck.se jim2311@aol.com kunta@cheerful.com scout@pluto.skyweb.net millennianet@earthlink.net orion@opportunitygroup.com mailbox@irantel.com server@san.rr.com mwa234@hotmail.com PROCESSING.. LX7.TXT From gedau@isa.mim.com.au Sat Jan 10 05:09:10 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: gedau@isa.mim.com.au (George Dau) Date: Sat, 10 Jan 1998 03:09:10 GMT David Lee Lambert wrote: ]Has anyone checked Linux for Year 2000 compliance? ] ]What do the vendors (RedHat, Caldera, etc.) have to say about it? ] ]What about the apps on Sunsite, like PostGreSQL? I have done some tests on a Linux box. The machine is mainly used as an X display for apps that run on other machines. It doesn't run anything much itself. It started as Slackware 1.2.13 and was hand-upgraded to 2.0.0. The hardware is an Osborne 486 DX-2/66 with 16Meg ram, Phoenix 80486 ROM BIOS PLUS Version 1.10 I set the date to Dec 1999 via the unix date command and let it roll-over, which it did no problems. I set the date to Dec 1999 in the BIOS and let it rollover to 2000 The `date` command reported Jan 01, 2000. I re-booted it and it went back to Jan 1990 (according to the bios). I set the date back to just before midnight and turned it off and let it roll-over while turned off. It booted as Jan 2000 (according to unix `date` command). I booted it again to check the cmos, it was 00:00:00 Jan 1990 again (according to the bios). I let it boot Linux and it was also 00:02:00 Jan 1990. So I have a non-compliant BIOS. I'll have to run ntpdate during the boot process to update the unix clock (or xntpd will fail and the date will be wrong). This one will roll-over fine on party night. -- ,-,_|\ George Dau, __ / * \ Unix (Solaris, DEC Unix, Linux), NT, Oracle, Internet. (OO) \_,--\_/ Home: gedau@pobox.com Work: gedau@isa.mim.com.au ( \/ ) v WWW: http://pobox.com/~gedau W--W Food for spambots: morilloruth@microjuris.com info@dproducts.be boulanger@dproducts.be caceeqi68@ma.interbroad.or.jp mwa234@hotmail.com yogiherbs@healthyherbs.com webmaster@www.brasilia.net plummer@ClipTrakker.com info2001@usa.net mramail@yahoo.com frant@mclafmall.com info@mclafmall.com earn@health.com ianc@atlantic-brands.com bulk@spck.se jim2311@aol.com kunta@cheerful.com scout@pluto.skyweb.net millennianet@earthlink.net orion@opportunitygroup.com mailbox@irantel.com server@san.rr.com mwa234@hotmail.com From cannon@nic.com Sat Jan 10 17:25:04 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: cannon@nic.com (Kevin Martin) Date: 10 Jan 1998 10:25:04 -0500 From the Red Hat 5.0 license: "YEAR 2000 ISSUES Red Hat Linux has been designed and tested from the beginning to work for our customers in the Year 2000 and beyond. Year 2000 readiness issues are more about testing, good practices, and user education than product warranty. We will continue to provide detailed information to customers about Year 2000 readiness, but contractual warranties specific to Year 2000 readiness are not appropriate given the nature of Year 2000 issues and the simple fact that a single technology provider, even one as well prepared for the Year 2000 as Red Hat, cannot solve all issues related to the transition to the Year 2000.... we recommend that customers read those [individual product] warranties to understand their rights. The information we disseminate about Year 2000 readiness does not constitute an extension of any warranty for Red Hat software products...." Any typos above are mine, since I'm touch-typing this. From adept@wport.com Sat Jan 10 18:40:48 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: "Roger J. Dyckman" Date: Sat, 10 Jan 1998 08:40:48 -0800 When was Red Hat bought by MS? Sounds like a classic Redmond warrantee to me. Roger Kevin Martin wrote in message <6983sg$abr$1@nic.com>... > >From the Red Hat 5.0 license: > >"YEAR 2000 ISSUES >Red Hat Linux has been designed and tested from the beginning to work >for our customers in the Year 2000 and beyond. Year 2000 readiness >issues are more about testing, good practices, and user education than >product warranty. We will continue to provide detailed information to >customers about Year 2000 readiness, but contractual warranties specific >to Year 2000 readiness are not appropriate given the nature of Year 2000 >issues and the simple fact that a single technology provider, even one as >well prepared for the Year 2000 as Red Hat, cannot solve all issues >related to the transition to the Year 2000.... we recommend that >customers read those [individual product] warranties to understand their >rights. The information we disseminate about Year 2000 readiness does >not constitute an extension of any warranty for Red Hat software >products...." > > >Any typos above are mine, since I'm touch-typing this. > From rasmusin@WPI.EDU Sat Jan 10 18:47:53 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: Frank Sweetser Date: 10 Jan 1998 11:47:53 -0500 "Roger J. Dyckman" writes: > When was Red Hat bought by MS? Sounds like a classic Redmond warrantee to > me. aw, c'mon, doesn't redhat get picked on enough? this is typical of *any* software company - "we're doing the best we can, but we can't give a 100% guarantee there's no bugs - after all, we're only human", especially on something as potentially big and subtle as the y2k problem. if you're going to judge redhat, then look at the reality of their packages, which is that they're of a much higher quality, and are much more resonsive to bug reports than the redmond giant. -- Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available paramount.res.wpi.net RedHat 5.0 Linux 2.0.33/2.1.78 i586 | at public servers linux: because a PC is a terrible thing to waste (ksh@cis.ufl.edu put this on Tshirts in '93) From saundo@schroedinger.adelaide.maptek.com.au Thu Jan 15 07:38:43 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: Chris Saunderson Date: 15 Jan 1998 16:08:43 +1030 "Roger J. Dyckman" writes: > When was Red Hat bought by MS? Sounds like a classic Redmond warrantee to > me. Actually, no, it's a standard disclaimer from most software vendors who are looking at the Y2K problem. just cuz it sounds corporate and uses the word "linux" in it, doesn't make it MS. -- Chris "Saundo" Saunderson Chris.Saunderson@adelaide.maptek.com.au Technical Support Engineer Telephone: (08) 8379 7333 Maptek Pty Ltd Fax: (08) 8379 7377 Powered by Linux, Jolt and the Orb. From schlegel@crocker.com Sun Jan 11 20:23:14 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: schlegel@crocker.com (Mark Schlegel) Date: 11 Jan 1998 18:23:14 GMT George Dau wrote: : David Lee Lambert wrote: : : ]Has anyone checked Linux for Year 2000 compliance? : ] linux like any unix should be OK for year 2000, the bios is what you should worry about. Also, unix I think will have a date problem of it's own at approx 2035 when the signed int that holds the number of seconds since 1/1/1970 will overflow. But 2035 is a LONG time in computer science, the chance the old unix absolute time from 1970 is still used by then is about 0 Mark From bonbahn.anti$pam@mn.uswest.net Mon Jan 12 02:50:24 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: "D. Scott Secor" Date: Sun, 11 Jan 1998 18:50:24 -0600 I thought BDS 16-bit Unix "bytes" the dust in 2005. Unix, per se, is supposedly good until 1/19/2038 a date at which many non-Unix C/C++ libraries also "buy the farm". Microsoft's C++ 4.x runtime libraries check out in 2036. I am uncertain about Linux, however. Sorry to be of so little help -- I'll attempt to be of less help in the future. Ciao, Scott "we could all be dead by 2038" Secor Mark Schlegel wrote in message <69b2mi$nvb$1@news2.ispnews.com>... >George Dau wrote: >: David Lee Lambert wrote: >: >: ]Has anyone checked Linux for Year 2000 compliance? >: ] > >linux like any unix should be OK for year 2000, the >bios is what you should worry about. Also, unix I think >will have a date problem of it's own at approx 2035 when the >signed int that holds the number of seconds since 1/1/1970 >will overflow. But 2035 is a LONG time in computer science, >the chance the old unix absolute time from 1970 is still >used by then is about 0 > >Mark > From slug@fast.co.za Mon Jan 12 10:51:50 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: slug@fast.co.za (Chris Anderson) Date: Mon, 12 Jan 1998 08:51:50 GMT "D. Scott Secor" wrote: >I thought BDS 16-bit Unix "bytes" the dust in 2005. Unix, per se, is >supposedly good until 1/19/2038 a date at which many non-Unix C/C++ >libraries also "buy the farm". >Microsoft's C++ 4.x runtime libraries check out in 2036. >I am uncertain about Linux, however. Sorry to be of so little help -- >I'll attempt to be of less help in the future. > >Mark Schlegel wrote in message <69b2mi$nvb$1@news2.ispnews.com>... >>George Dau wrote: >>: David Lee Lambert wrote: >>: >>: ]Has anyone checked Linux for Year 2000 compliance? >>: ] >> >>linux like any unix should be OK for year 2000, the >>bios is what you should worry about. Also, unix I think >>will have a date problem of it's own at approx 2035 when the >>signed int that holds the number of seconds since 1/1/1970 >>will overflow. But 2035 is a LONG time in computer science, >>the chance the old unix absolute time from 1970 is still >>used by then is about 0 >> The jury is still out on Linux. The tests are still happening. What we KNOW at this point is: 1) Earlier kernels such as 1.2.13 have an error in calculating leap years. Later Version 2 kernels (2.0.30 was tested) have fixed this problem. 2) Linux uses exactly the same method as NT 4, i.e. read the RTC direct , convert the two digit year to 20xx. CMOS byte hex 32 is NOT maintained directly. In other words accessing the BIOS (via DEL at bootup) is probably the only way to set the 20xx range by changing CMOS hex 32 to '20'. However, once set, this will work correctly until 2038. 3) The usual Unix two digit date application bugs still apply. The net result is that Linux itself is capable of operating into 2000, but applications must be checked. ------------------------------------------------------------------------ Chris Anderson email: slug@fast.co.za Y2K Cinderella Project webmaster@cinderella.co.za http://www.cinderella.co.za Striving for Year 2000 Compliance ------------------------------------------------------------------------ From viro@math.psu.edu Thu Jan 15 03:54:57 1998 Newsgroups: comp.software.year-2000,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: viro@math.psu.edu (Alexander Viro) Date: 14 Jan 1998 20:54:57 -0500 Yup. Exactly. And I have no complaints about this racket. I don't take part in it, but if there are fools they will find a way to lose their money. Barnum was 100% right here. As for the silly test thing - well, there are hundreds of areas where bugs exist. IP fragmentation for one. Buffer overflow exploits. If Y2K doesn't lead to immedeate problems - well, it is one more such area. And nothing more. Some applications are buggy - big deal! Most applications are. Some bugs are around Y2K. So what? I see nothing technically special here. But "Buffer overflow complaint" is not _kewl_. (Much more serious, IMHO). That's racket - plain and simple. I have nothing against gentle ripping of CEOs. Just don't f*ck my brain with all this hoopla. Cheers, Al [Followups to comp.os.linux.misc trimmed] From jimi@inf.bme.hu Thu Jan 15 15:33:13 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: rauznitz balazs Date: Thu, 15 Jan 1998 14:33:13 +0100 On 11 Jan 1998, Alexander Viro wrote: > > Guys, it is very simple. Set the date to Dec 31 1999 and let the thing go. > A lot of people tried it and everything was OK. BTW, it could be done on > any OS. But it would be too simple and would break the nice racket around > Y2K compatibility... The only problem is that big, serious machines that suffer from Y2K cannot just reset the time to any date, because this would cause the problem right away. You can do it on your linux box at home, but there would not be any problems if it gave 1900 after 1999, anyway. b From eugene@cs.umb.edu Tue Jan 13 23:36:39 1998 Newsgroups: comp.software.year-2000,comp.os.linux.misc,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: eugene@cs.umb.edu (Eugene O'Neil) Date: Tue, 13 Jan 98 21:36:39 GMT In article <69c1bj$g1p$1@cyberdex.cuug.ab.ca>, trever@cyberdex.geniers.cuug.ab.ca (Trever Miller) wrote: >Mark Schlegel (schlegel@crocker.com) wrote: >> linux like any unix should be OK for year 2000, the >> bios is what you should worry about. Also, unix I think >> will have a date problem of it's own at approx 2035 when the >> signed int that holds the number of seconds since 1/1/1970 >> will overflow. But 2035 is a LONG time in computer science, >> the chance the old unix absolute time from 1970 is still >> used by then is about 0 > >hrm. And that is... roughly 40 years from now. Gee, there's COBOL code >in use that's older than that, is there not? > >Here we go again.,.. notice that he said this will occur when a "signed int overflows". Assuming you are using 32-bit integers, that will be in 2035. But I think that by that date, we will all probably be using 64-bit integers, at the very least. A 64 bit integer takes 2 to the power of 32 times longer to overflow, so I wouldn't worry about it... -Eugene From dpbsmith@world.std.com Thu Jan 15 02:08:21 1998 Newsgroups: comp.software.year-2000,comp.lang.c++,comp.os.linux.advocacy,alt.alien.vampire.flonk.flonk.flonk Subject: Re: Is Linux year 2000 compliant? From: dpbsmith@world.std.com (Daniel P. B. Smith) Date: Thu, 15 Jan 1998 00:08:21 GMT In article , Flaagg wrote: >Daniel 'Doc' Sewell < dochood@icon-st.NOSPAM.com > says... > >We here at AAVFFF believe we have discovered a simple, low cost answer to >the 'Y2K' fiasco, and urge all seriously concerned programmers, >businessmen and personal computer users to DEMAND that their local >governments take a clear-eyed look into the 'Let's Just Call All Of The >Years After 1999 "Gertrude"' solution, before it's too late. Beware of geeks bearing grifts. -- Daniel P. B. Smith dpbsmith@world.std.com From viro@math.psu.edu Fri Jan 16 10:31:30 1998 Newsgroups: comp.software.year-2000,comp.lang.c++,comp.os.linux.advocacy,alt.alien.vampire.flonk.flonk.flonk Subject: Re: Is Linux year 2000 compliant? From: viro@math.psu.edu (Alexander Viro) Date: 16 Jan 1998 03:31:30 -0500 What magical about 1/1/2000? They'll screw themselves up before - they are switching to NT. The point is that there are _many_ ways to go belly up. And Y2K is not the most serious in this list. Read CERT advisories. As for calling them up - nah! I'm too lazy to do this work for you. If you need some fear around - do it yourself. Shit, Wall Street had a nice time last year - due to NT inability to cope with server work. It was waay before 1/1/2000. But 2000 sounds sooo apocaliptic... Barnum would be proud. To be serious - there are bugs in the software. There were problems, there are problems and there will be problems. Ever. When one finds a problem he should inform CERT and try to find a fix. That's the honest way. Period. When you start to blow up the significance of some bug it makes me suspicious. When you start to _explain_ this bug to manangers I become very suspicious. When you say them that they should hire you and you'll save their souls or else they'ld go to hell - well, everything is clear. Somebody had a hard look at Michelangelo Virus Hoax and realized that he can make a nice buck on slightly modified version of this crap. This topic has nothing with programming - it's purely sociopsychological thing. And it is way offtopic to comp.os.linux.* Stop trolling here. And have a good racket, grey brothers! Good luck to you! Al From paul.flinders@finobj.com Fri Jan 16 16:32:31 1998 Newsgroups: comp.software.year-2000,comp.lang.c++,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: Paul Flinders Date: 16 Jan 1998 14:32:31 +0000 kiyoinc@ibm.net (cory hamasaki) trolled: > So, my vocal little Unix Weenie, have you looked at tm underscore year in > time.h recently? Ponder the meaning of the comment for tm_year and tremble > in fear for Unix, Linux, ....... Lemme see... struct tm { int tm_sec; /* seconds after the minute - [0,59] */ int tm_min; /* minutes after the hour - [0,59] */ int tm_hour; /* hours since midnight - [0,23] */ int tm_mday; /* day of the month - [1,31] */ int tm_mon; /* months since January - [0,11] */ int tm_year; /* years since 1900 */ int tm_wday; /* days since Sunday - [0,6] */ int tm_yday; /* days since January 1 - [0,365] */ int tm_isdst; /* daylight savings time flag */ }; Integer years since 1900? Nope I'm not trembling. 1900's just a base date, no more or less significant than 0AD or whatever the Hebrew calander uses (Emacs tells me that we're in year 5758 of the Hebrew calander so stick that in your Y2K pipe and smoke it). If I put 100 in here (which I could do even if an "int" on my system was an 8 bit signed quantity) that would represent 2000. Since an int on my system is 32 bits I think that a struct tm is good for a while yet. Unless you'd care to modify your superior and largely content-free tone and tell us just what you think the problem is. > ...... Unix, Linux, C and C++ have a huge vulnerbility Neither the C, nor C++ language definitions have date specific functionality and so are outside the scope of the Y2K problem. ANSI & Posix libraries have date & time conversions between specified representations but all of the representations have no difficulty representing dates int the next century correctly. > and lots of Unix Weenies did it horribly wrong. So did lots of COBOL weenies, FORTRAN Weenies, Database Weenies, assembler Weenines and others. The Y2K problem is *not* an OS thing (in general - I can't think of an OS where the *native* date representation has problems) Yes, some *applications* writers wrote code like printf("...... 19%d.....", t->tm_year,.......); instead of printf("...... %d.....", 1900+t->tm_year,.......); But that does not constitute a vulnerability in Unix, C or C++, just in the errant application, *even* if they were encouraged to do so by the comment in time.h. -- Paul From news@elmbronze.demon.co.uk Sat Jan 17 00:46:01 1998 Newsgroups: comp.software.year-2000,comp.lang.c++,comp.os.linux.advocacy Subject: Re: Is Linux year 2000 compliant? From: Dave Eastabrook Date: Fri, 16 Jan 1998 22:46:01 +0000 on Fri, 16 Jan 1998 Paul Flinders wrote > >kiyoinc@ibm.net (cory hamasaki) trolled: > >> So, my vocal little Unix Weenie, have you looked at tm underscore year in >> time.h recently? Ponder the meaning of the comment for tm_year and tremble >> in fear for Unix, Linux, ....... > >Unless you'd care to modify your superior and largely content-free >tone and tell us just what you think the problem is. > >> ...... Unix, Linux, C and C++ have a huge vulnerbility >> and lots of Unix Weenies did it horribly wrong. Yes indeed. > >So did lots of COBOL weenies, FORTRAN Weenies, Database Weenies, >assembler Weenines and others. Yes indeed. > >The Y2K problem is *not* an OS thing (in general - I can't think of an >OS where the *native* date representation has problems) You don't know enough OS's. Or enough about any you do know. Hardware's the least of the problems, but try that too. > >Yes, some *applications* writers wrote code like > Yes indeed. Except I'd replace "some" by "many". Cory, I've seen postings rise from about 50 a day, less at weekends, to 250+ a day now in csy2k (comp.software.year-2000 for the uninitiated). We've all fought denial and ignorance till it comes out of our arses. I admire and respect you, pal, you've got more stamina and/or more patience than me with these denial-heads. Anyway, this guy here doesn't count for much. It's unlikely he's in a position to affect much of anything. Let him lie in blissful ignorance. For those of sound mind, but a little ignorance THERE IS NO PLATFORM OR LANGUAGE SAFE FROM THE MACHINATIONS OF USERS, ANALYSTS AND PROGRAMMERS. Or DBAs, Technical and system programmers / administrators. PHMs. Any language, or application running on any platform MIGHT be non-compliant. COBOLlers have got the message - shame about the C guys. And their employers/clients. Byeeee. Sorry Cory, you're on your own here now. I've spent far far too much time on Y2K, and csy2k. I can't lurk - I've never been good as a spectator. I tried, and it lasted about three days. I read something - and my fingers start twitching. It's kind of like looking over the shoulder of someone fumbling with a dump. Your fingers twitch in the air "F REGISTERS". "F 01A43860". Your left eye starts a nervous tick. And before you know it, the guy's on the deck, and you're sitting in the chair, chasing down displacement AF8 on register 10. And it's time I spent time with my wife and kids, and on all those little and large chores around the house. And on the golf course (or in the pub). So - I'm off. Unsubscribing from csy2k (shock horror). Good Luck to you and all in csy2k. To the guillotine with Denial-Heads!! :Dave -- Dave Eastabrook. Elmbronze Ltd. Y2K Consultant. 25+ years IBM Mainframes. Available NOW to give your Y2k project some chance of succeeding. Without me you're sunk without a trace. Of course trainees are a lot cheaper .... LOL. http://www.elmbronze.demon.co.uk/year2000/ also /IBM/ or /telework/ PROCESSING.. LX8.TXT From lamber45@EGR.msu.edu Thu Feb 05 19:42:39 1998 Newsgroups: comp.software.year-2000,alt.2600,comp.os.linux.advocacy Subject: Another fail date for UNIX: 2048 (passwd aging) From: David Lee Lambert Date: Thu, 5 Feb 1998 12:42:39 -0500 Some UNIX passwd files use a two-digit base64 encoded number to represent the week when the password was last changed, since 1970. Thus, it will roll over roughly 175 days through 2048. Shadow password files don't have the same problem: they use ASCII-encoded integers in seperate fields to represent the same stuff, or at least the Linux ones do. David Lee Lambert MHm 16x20 Hack Programmer and Student Admin of lmert.dyn.ml.org http://lmert.dyn.ml.org My web pages are at http://web.egr.msu.edu/~lamber45 PROCESSING.. UX1.TXT From adam@consulting-4-y2k.com Fri Jan 02 02:36:19 1998 Newsgroups: comp.software.year-2000 Subject: Re: Unix Denial From: Mark S Adam Date: Thu, 01 Jan 1998 16:36:19 -0800 Evan Robatino wrote: > > > RandallBart wrote: > > > > > > The ultimate in inadequate Y2K testing: > > > > > > A friend works on a military system which is used by Germany, New > > > Zealand and several other countries. I was discussing Y2K with him and > > > he said (derisively) that one of their customers had asked if their > > > system has been validated for Y2K. The response: This is a Unix > > > system, and therfore it *can't* have Y2K bugs. He insists that they > > > will not check their software for Y2K compliance, and that no Unix shops > > > test for Y2K compliance, because no Unix programmer would ever write > > > non-compliant code. > > > > > > They will be sorely embarassed on The Day, when their system crashes > > > over some minor bug. [snip - sorry tony] > I just HAVE to respond to this one. Has the person who's so certain > that *no* UNIX system can have Y2k bugs thought of checking for: > > (1) Scripts with "19%y" variables (which will of course yield "1900" in > the year 2000 when a %Y variable (which will yield "2000" in Y2k) should > have been used. I've seen this in an actual UNIX script. > > (2) Crons containing such constructs as: > > S199[0-9] > > to match the current year. (This is used with a file transfer package > I'm familiar with that generates log files with file names > starting with "Syyyy" where "yyyy" is the four-digit year. The idea is > to run a cron at specified times to delete outdated log files. > Obviously, the scheme illustrated above is non-Y2k-compliant; you need > more metacharacters as follows: > > Y[1-9][0-9][0-9][0-9] > > to ensure that the cron recognizes and removes log files created after > 1999. (This example was somewhat sketchy since I didn't have the > documentation for this example immediately available to me, but I think > it illustrates my point.) [snip] If they have any C code then just grep for tm_year and I'll bet that most of what you find will have problems. The problem is that the tm_year element of struct tm is defined as the current year - 1900. In 2000 tm_year will be 100. This causes some intesting situations if the programmer was expecting a 2-digit year: * In properly fundtioning leap year code it will say that 100 is not a leap year. And we know 2000 is. * If a string or file name is created using the number and there wasn't room for the extra digit then there could be a buffer overrun. * If a date string is created without any separators then the YYMMDD date created will actually be 1000101. Any other code reading this would interpret the date as day 10 of an invalid month in 2010 (or 1910 if you're doubly screwed). After finding out about the tm_year and leap year interaction I changed from a believer to a zealot. It was the first time I saw a case where even a good programmer could get nailed. -- mark---------------- Y2K Consulting Senior Consultant / Stratus Specialist adam@consulting-4-y2k.com <=== Use this for all mail, including replies. PROCESSING.. UX2.TXT From arnold.trembley@worldnet.att.net Sat Jan 03 11:44:47 1998 Newsgroups: comp.software.year-2000 Subject: Re: Unix Denial From: Arnold Trembley Date: Sat, 03 Jan 1998 03:44:47 -0600 RandallBart wrote: > > Tony Walton wrote: > > > > RandallBart wrote: > > > > > > NOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!! > > > > To what, precisely? > > > > T > > I will assume the code was originally: > > printf("%d",tm_year) > > and was changed to > > printf("%d",tm_year%100) > > I leave it as an exercise to the reader to determine why adding "%100" > failed to fix the program. (This is the world's most ubiquitous > non-Cobol Y2K bug). Uh, does the year after "99" become "0", or " "? Does the day after 12/31/0 become 12/31/1? > -- > I |\ Randall Bart mailto:Barticus@usa.spam.net > L |/ > o |\ Barticus@worldnet.att.spam.net Barticus@hotmail.spam.com > v | \ 1-818-985-3259 Please reply without spam > e |\ > Y |/ Panic in the Year Zero Zero: http://members.aol.com/PanicYr00 > o |\ > u |/ Have you solved http://members.aol.com/PanicYr00/Sequence.html Arnold Trembley PROCESSING.. UX3.TXT From mark0young@aol.com Sat Jan 03 19:37:47 1998 Newsgroups: comp.software.year-2000 Subject: Re: Unix Denial From: mark0young@aol.com (Mark0Young) Date: 3 Jan 1998 17:37:47 GMT >> printf("%d",tm_year%100) In article <68l1b5$4oj@bgtnsc03.worldnet.att.net>, Arnold Trembley writes: >Uh, does the year after "99" become "0", or " "? Does the day after >12/31/0 become 12/31/1? When tm_year goes 100, tm_year%100 becomes 0, so %d would format that as 0 (single digit). One can change the formatting string to produce 2 digits, e.g., %02d to produce a leading zero if needed (so printf("%02d",0) prints 00. Or one can use %2d and a leading space will be used if the number is only one digit. PROCESSING.. UX4.TXT From tony.walton@UK.Sun.COM.PLEASE.REMOVE.THIS.TO.REPLY Fri Jan 02 13:07:55 1998 Newsgroups: comp.software.year-2000 Subject: Re: Unix Denial From: Tony Walton Date: Fri, 02 Jan 1998 11:07:55 +0000 Mark S Adam wrote: > > > [snip - sorry tony] > > > > > I just HAVE to respond to this one. Has the person who's so certain > > that *no* UNIX system can have Y2k bugs thought of checking for: > > > > (1) Scripts with "19%y" variables (which will of course yield "1900" in > > the year 2000 when a %Y variable (which will yield "2000" in Y2k) should > > have been used. I've seen this in an actual UNIX script. > > > > (2) Crons containing such constructs as: > > > > S199[0-9] > > > > to match the current year. (This is used with a file transfer package > > I'm familiar with that generates log files with file names > > starting with "Syyyy" where "yyyy" is the four-digit year. The idea is > > to run a cron at specified times to delete outdated log files. > > Obviously, the scheme illustrated above is non-Y2k-compliant; you need > > more metacharacters as follows: > > > > Y[1-9][0-9][0-9][0-9] > > > > to ensure that the cron recognizes and removes log files created after > > 1999. (This example was somewhat sketchy since I didn't have the > > documentation for this example immediately available to me, but I think > > it illustrates my point.) > > [snip] > > If they have any C code then just grep for tm_year and I'll bet that > most of what you find will have problems. > > The problem is that the tm_year element of struct tm is defined as the > current year - 1900. In 2000 tm_year will be 100. This causes some > intesting situations if the programmer was expecting a 2-digit year: > > * In properly fundtioning leap year code it will say that 100 is not a > leap year. And we know 2000 is. > > * If a string or file name is created using the number and there wasn't > room for the extra digit then there could be a buffer overrun. > > * If a date string is created without any separators then the YYMMDD > date created will actually be 1000101. Any other code reading this would > interpret the date as day 10 of an invalid month in 2010 (or 1910 if > you're doubly screwed). > > After finding out about the tm_year and leap year interaction I changed > from a believer to a zealot. It was the first time I saw a case where > even a good programmer could get nailed. I'm baaack! :-) I certainly didn't mean to say that "Unix has no Y2000 problem" - sorry if anyone misunderstood me to say that. A quick scan of our SunSolve bug database for bugs in Sun-supplied software containing the keyword "y2000" shows that Mark's analysis is spot-on. Although the Unix *kernel* itself doesn't know or care what century it is (Bad Things happen in-kernel in 2038, but that's another story) the vast majority of bugfixes are to utilities which will show dates as "01-01-100" or "01-01-19100" on 20000101; mainly these use the (erroneous) constructions printf("19%d",tm_year) or printf("%d",tm_year) which assume that tm_year is a "year of century" count when in fact it's a "years since 1900" count. As seems to be usual, the fixes are trivial but the places where tm_year is used firstly have to be found and then the required fix (something like using printf("%d",tm_year%100) for instance) has to be applied, the utility recompiled, tested, etc etc. I'd certainly urge the original poster to reconsider - Unix is potentially as millennium-sensitive as anything else. -- Tony Speaking for myself, not for Sun PROCESSING.. UX5.TXT Nick Upson wrote: > > > H/W is a good point, none of the UNIX box suppliers I've seen > have commented either way, um, make large note to check. Sun's Compliant Products List at http://www.sun.com/y2000/cpl.html gves hardware details (basically it should all be OK except for a couple of exceptions which will require PROM upgrade or patch). Regards Tony PROCESSING.. UX6.TXT From Barticus@worldnet.att.spam.net Sat Jan 03 00:59:08 1998 Newsgroups: comp.software.year-2000 Subject: Re: Unix Denial From: RandallBart Date: Fri, 02 Jan 1998 14:59:08 -0800 Tony Walton wrote: > > RandallBart wrote: > > > > NOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!!!!!!!!!! > > To what, precisely? > > T I will assume the code was originally: printf("%d",tm_year) and was changed to printf("%d",tm_year%100) I leave it as an exercise to the reader to determine why adding "%100" failed to fix the program. (This is the world's most ubiquitous non-Cobol Y2K bug). -- I |\ Randall Bart mailto:Barticus@usa.spam.net L |/ o |\ Barticus@worldnet.att.spam.net Barticus@hotmail.spam.com v | \ 1-818-985-3259 Please reply without spam e |\ Y |/ Panic in the Year Zero Zero: http://members.aol.com/PanicYr00 o |\ u |/ Have you solved http://members.aol.com/PanicYr00/Sequence.html