terrell@druhi.ATT.COM (TerrellE) (06/23/89)
Will your software make it into the 21st century? Does it cope with the Gregorian calendar reform of the 16th century? I was amused to find that allegedly state of the art scheduling software, TimeLine, is broken for the year 2000. So is MS DOS. The Gregorian calendar reform makes every year evenly divisible by 4 a leap year EXCEPT for century years. Consequently there is no January 29, 2000. Perhaps software developers are following in the footsteps of the Protestants who refused to recognize Pope Gregory's reform, saying that they'd rather be out-of-synch with the sun than in-synch with Rome! How much other software is broken? Consider this business opportunity: Form a company "21st Century Software". Wait until about 1998, and then offer a cheap consulting service to determine if customer computer systems will be broken in 2000. Then for a higher price, offer to fix the problem. Of course the rates will rapidly increase as February 28 draws nigh and payroll managers cower in fear... Terrell (att!druhi!terrell)
neal@druhi.ATT.COM (Neal D. McBurnett) (06/24/89)
in article <4342@druhi.ATT.COM>, terrell@druhi.ATT.COM (TerrellE) says: > I was amused to find that allegedly state of the art scheduling software, > TimeLine, is broken for the year 2000. So is MS DOS. > > The Gregorian calendar reform makes every year evenly divisible by 4 a > leap year EXCEPT for century years. Consequently there is no January 29, > 2000. No, no, no. First, of course, every year has a January 29th. I'll assume we're talking about Feburary 29th. Second, the Gregorian calendar says that years divisible by 4 are leap years, except, years divisible by 100 are NOT leap years, except, years divisible by 400 are leap years. Either the Gregorian calendar or more recent proposals have suggested these refinements: years divisible by 4000 are NOT leap years. years divisible by 20000 are leap years. This makes the calendar keep in step with the tropical year for about the next 150000 years. A tropical year is 365.242194 days or so. I'm not sure, though, to what extent this might be affected by our more recent knowledge of the rate of change of the length of a year. I guess that the periodic addition of leap seconds makes the year average out to the proper value for use in the above calculations.... Anyway, the year 2000 is a leap year, and software developers are safe until 2100. -Neal McBurnett, neal@druhi.att.com or att!druhi!neal
silvert@cs.dal.ca (Bill Silvert) (06/25/89)
In article <4342@druhi.ATT.COM> terrell@druhi.ATT.COM (TerrellE) writes: >The Gregorian calendar reform makes every year evenly divisible by 4 a >leap year EXCEPT for century years. Consequently there is no January 29, >2000. Yes there is. There is also a February 29, 2000. Century years divisible by 400 are leap years. To be very precise, years divisible by 4000 are not leap years, so 2000 is a leap year, but 4000 is not. -- Bill Silvert, Habitat Ecology Division. Bedford Institute of Oceanography, Dartmouth, NS, Canada B2Y 4A2 UUCP: ...!{uunet,watmath}!dalcs!biomel!bill Internet: biomel@cs.dal.CA BITNET: bs%dalcs@dalac.BITNET
clf3678@ultb.UUCP (C.L. Freemesser) (06/26/89)
In article <4342@druhi.ATT.COM> terrell@druhi.ATT.COM (TerrellE) writes: >Will your software make it into the 21st century? Does it cope with the >Gregorian calendar reform of the 16th century? > >I was amused to find that allegedly state of the art scheduling software, >TimeLine, is broken for the year 2000. So is MS DOS. > >The Gregorian calendar reform makes every year evenly divisible by 4 a >leap year EXCEPT for century years. Consequently there is no January 29, >2000. (rest deleted) Are you SURE about that? My birthday is January 29! >Terrell (att!druhi!terrell) Chris Freemesser, Rochester Institute of Technology | What I like : BITNET: %clf3678@RITVAX | 1) My Atari ST USENET: Just reply and hope it gets through | 2) My '77 Mercury "Another brilliant mind ruined by higher education" | 3) Coke Classic
bob@omni.com (Bob Weissman) (06/27/89)
In article <4342@druhi.ATT.COM>, terrell@druhi.ATT.COM (TerrellE) writes: > The Gregorian calendar reform makes every year evenly divisible by 4 a > leap year EXCEPT for century years. Consequently there is no January 29, > 2000. I understand you meant February, not January. But 2000 is divisible by 400. Therefore, it IS a leap year. -- Bob Weissman Domainish: bob@omni.com UUCPish: ...!{amdahl,apple,pyramid,tekbspa,uunet}!koosh!bob
jimb@athertn.Atherton.COM (Jim Burke) (06/27/89)
In article <4342@druhi.ATT.COM> terrell@druhi.ATT.COM (TerrellE) writes: > >Consequently there is no January 29, 2000. So what are they going to do, skip right over it and go on to January 30 and January 31??? I vote that if we are going to eliminate days in the middle of the months, we excise April 15 (tax day) or November 21 (my birthday). What do you think, can we pull it off????..... -- Jim Burke (408) 734-9822 (temp) | I don't know nothin' 'bout birthin' jimb@Atherton.COM | no babies, Miss Scarlet! {decwrl,sun,hpda,pyramid}!athertn!jimb |
ralf@b.gp.cs.cmu.edu (Ralf Brown) (06/27/89)
In article <4342@druhi.ATT.COM> terrell@druhi.ATT.COM (TerrellE) writes: }Will your software make it into the 21st century? Does it cope with the }Gregorian calendar reform of the 16th century? } }I was amused to find that allegedly state of the art scheduling software, }TimeLine, is broken for the year 2000. So is MS DOS. } }The Gregorian calendar reform makes every year evenly divisible by 4 a }leap year EXCEPT for century years. Consequently there is no January 29, }2000. Sorry, but there IS a February 29, 2000. Century years are not leap years UNLESS they are evenly divisible by 400 (the calendar prior to the reform gained about 3.2 days per 400 years). However, lots of other software is likely to break because the century is no longer 19. For example, RFC 822 mail uses the year mod 100. We'll have lots of fun with mailers trying to figure out why the year is suddenly 00. -- {harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) ARPA: RALF@CS.CMU.EDU |"The optimist is the kind of person who believes a FIDO: Ralf Brown 1:129/46 | housefly is looking for a way out."--Geo.J.Nathan BITnet: RALF%CS.CMU.EDU@CMUCCVMA -=-=-=-=-=- DISCLAIMER? I claimed something?
shapiro@rb-dc1.UUCP (Mike Shapiro) (06/28/89)
In article <4342@druhi.ATT.COM> terrell@druhi.ATT.COM (TerrellE) writes: >Will your software make it into the 21st century? Does it cope with the >Gregorian calendar reform of the 16th century? ... >The Gregorian calendar reform makes every year evenly divisible by 4 a >leap year EXCEPT for century years. Consequently there is no January 29, >2000. ... As you probably realize by now, 2000 is a leap year with a February, not January, 29. However, you are right that much software will not likely make it safely into or through the last year of the century and the millenium. One current example is Norton Utilities routine TimeMark (TM), which reports that December 31, 1999, is a Friday, and January 1, 2000, is a Sunday. Every date from then on is one day-of-the-week off. (January 1, 2000, will be a Saturday. We'd better plan for a good, long weekend because we'll have a busy week coming up. And of course we'll have a busy year celebrating the approach of the 21st century a year later.) -- Michael Shapiro, Encore Computer Corporation (formerly Gould/GSD) 15378 Avenue of Science, San Diego, CA 92128 (619)485-0910 UUCP: shapiro@rb-dc1 (This location will close, starting July 10. I will be moving on.)
leonard@bucket.UUCP (Leonard Erickson) (06/28/89)
In article <4342@druhi.ATT.COM> terrell@druhi.ATT.COM (TerrellE) writes:
<Will your software make it into the 21st century? Does it cope with the
<Gregorian calendar reform of the 16th century?
<
<I was amused to find that allegedly state of the art scheduling software,
<TimeLine, is broken for the year 2000. So is MS DOS.
<
<The Gregorian calendar reform makes every year evenly divisible by 4 a
<leap year EXCEPT for century years. Consequently there is no January 29,
<2000.
Sorry, but you got it wrong. Century years are leap years if they are
evenly divisible by 400! 1900 wasn't a leap year (but several programs
like Lotus and dBase think it was!) 2000 is a leap year. And MS-DOS avoids
the problem by stopping at midnight Dec 31, 2099.
Repeat, there *is* a Feb 29 in the year 2000.
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Shortlandry@enginr.dec.com (06/28/89)
"In article <4342@druhi.ATT.COM> terrell@druhi.ATT.COM (TerrellE) writes:
">Will your software make it into the 21st century? Does it cope with the
">Gregorian calendar reform of the 16th century?
"....
How much software that you're using now do you really think you'll still
be using in the year 2000?
How much software that you used 10 years ago are you using now?peggy@ddsw1.MCS.COM (Peggy Shambo) (06/28/89)
In article <4345@druhi.ATT.COM> neal@druhi.ATT.COM (Neal D. McBurnett) writes: > >Anyway, the year 2000 is a leap year, and software developers are safe until >2100. Just out of curiosity, I pulled up my SideKick calendar. The year 2000 has a February 29, but I couldn't test on the year 2100 (they planning it to be obsolete by then? :-) as it only went up to the year 2099. -- _____________________________________________________________________________ Peg Shambo | Anybody know of any IDMS/ADSO positions in peggy@ddsw1.mcs.com | the South of England? (London, Southampton, | Portsmouth, Bournemouth would all be nice)
hjg@amms4.UUCP (Harry Gross) (06/28/89)
In article <4342@druhi.ATT.COM> terrell@druhi.ATT.COM (TerrellE) writes: >Will your software make it into the 21st century? Does it cope with the >Gregorian calendar reform of the 16th century? [stuff deleted] >The Gregorian calendar reform makes every year evenly divisible by 4 a >leap year EXCEPT for century years. Consequently there is no January 29, ^^^^^^^ >2000. Um - that ought to be February :-) By the way, the proper determination is just a wee bit more than that stated above. Specifically, a leap year exists if: 1) the year is divisible by 4 AND 2) the year is NOT divisible by 400 thus, the years 1700, 1800 and 1900 were leap years, but 2000 will NOT be a leap year, and 2100 WILL be. On the other hand, does anyone really expect their software to be up and running in the year 2100? :-) By the same token, I expect that DOS will have been replaced by something else by the year 2000 (perhaps DOS 9.8 :-) and Microsoft and IBM will no doubt have fixed the problem in that release :-) -- Harry | reserved for | something really Internet: hjg@amms4.UUCP (we're working on registering)| clever - any UUCP: {jyacc, qtny, rna, bklyncis}!amms4!hjg | suggestions?
hjg@amms4.UUCP (Harry Gross) (06/28/89)
Excuse me - a correction to my correction.
rule 2) should state:
2) the year ends in 00 and is NOT divisible by 400
also, the AND at the end of rule 1) should be an OR.
Thus:
1) the year is divisible by 4 and does NOT end in 00 OR
2) the year ends in 00 and is NOT divisible by 400
Why can't I see these things BEFORE the article goes out? Oh well :-)
--
Harry | reserved for
| something really
Internet: hjg@amms4.UUCP (we're working on registering)| clever - any
UUCP: {jyacc, qtny, rna, bklyncis}!amms4!hjg | suggestions?desnoyer@apple.com (Peter Desnoyers) (06/29/89)
In article <3195@shlump.dec.com> landry@enginr.dec.com writes: > How much software that you're using now do you really think you'll still > be using in the year 2000? > > How much software that you used 10 years ago are you using now? Personally, I think the question should be re-phrased: Will your DATA make it into the next century? If it does, what are you going to use to read it for the first few months of the new millenia? If programmers are doing dates wrong in 1989, why do you think they will do any better in 1998? I think a lot of software companies will learn that 2000 is a leap year the way everyone else will - by the inevitable trumpeting on TV news programs which will probably start sometime in 1999. How much are you willing to bet that they can get upgrades out by the end of the year? Peter Desnoyers Apple ATG (408) 974-4469
allbery@ncoast.ORG (Brandon S. Allbery) (06/29/89)
As quoted from <4342@druhi.ATT.COM> by terrell@druhi.ATT.COM (TerrellE): +--------------- | Will your software make it into the 21st century? Does it cope with the | Gregorian calendar reform of the 16th century? | | I was amused to find that allegedly state of the art scheduling software, | TimeLine, is broken for the year 2000. So is MS DOS. | | The Gregorian calendar reform makes every year evenly divisible by 4 a | leap year EXCEPT for century years. Consequently there is no January 29, | 2000. +--------------- (1) Presumably, you meant February 29. (2) You got it wrong. The rules for the Gregorian calendar are: a leap day every 4 years, EXCEPT in the year preceding the beginning of the next century (remember, the 21'st century starts in 2001, not 2000; there is no year 0) EXCEPT when that year is divisible by 400, in which case it again has a leap day. Thus, the year 2000 *is* a leap year. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
phipps@garth.UUCP (Clay Phipps) (07/06/89)
In article <5561@athertn.Atherton.COM> jimb@athertn.UUCP (Jim Burke) writes: >In article <4342@druhi.ATT.COM> terrell@druhi.ATT.COM (TerrellE) writes: >> >>Consequently there is no January 29, 2000. > >I vote that if we are going to eliminate days in the middle of the months, >we excise April 15 (tax day) ... ^^ ^^^^^^^ As Professor Kingsfield often instructed his students: "never assume !". Under the current IRS regulations, Tax Day in the year 2000 will be Monday, April *17*, not April 15, because the 15th will be a Saturday. Depending on the precise wording of the IRS regulations then in effect, eliminating either April 15 or April 17 may not help any of us taxpayers :-(. The above reminder is presented as a public service to facilitate advance tax planning by readers of the net :-). -- [The foregoing may or may not represent the position, if any, of my employer, ] [ who is identified solely to allow the reader to account for personal biases.] Clay Phipps Intergraph APD: 2400#4 Geng Road, Palo Alto, CA 93403; 415/494-8800 UseNet: {apple,ingr,pyramid,sri-unix}!garth!phipps EcoNet: cphipps
hjg@amms4.UUCP (Harry Gross) (07/07/89)
In article <381@amms4.UUCP> I wrote: >is just a wee bit more than that stated above. Specifically, a leap year >exists if: > > 1) the year is divisible by 4 AND > 2) the year is NOT divisible by 400 > >thus, the years 1700, 1800 and 1900 were leap years, but 2000 will NOT be >a leap year, and 2100 WILL be. In article <382@amms4.UUCP> I modified that to read: >rule 2) should state: > >2) the year ends in 00 and is NOT divisible by 400 > >also, the AND at the end of rule 1) should be an OR. > >Thus: >1) the year is divisible by 4 and does NOT end in 00 OR >2) the year ends in 00 and is NOT divisible by 400 In a private message from neubauer@bsu-cs.bsu.edu (Paul Neubauer), he wrote: >You have the century years backwards! 1700, 1800, and 1900 were NOT leap >years, but 2000 will be. No flame, just a warning: check this algorithm >BEFORE you code it into something that might be around for very long. I replied to him that I was fairly certain that I had it right, but that I would check anyway. Well, I had it wrong (open mouth, insert foot, close mouth :-) Paul was right, and I _did_ have the centuries backwards. A correct test for leap year, therefore, is: if (year%4 == 0 && year%100 != 0 || year%400 == 0) printf("LEAP YEAR!"); That test comes from the K & R book, from their date conversion routine somewhere around page 103 (113?). I should have looked before I leapt :-) Sorry for the unnecessary noise, but I did want to post the correction (and the apology :-). Later, -- Harry Gross | reserved for | something really Internet: hjg@amms4.UUCP (we're working on registering)| clever - any UUCP: {jyacc, qtny, rna, bklyncis}!amms4!hjg | suggestions?
dal@syntel.UUCP (Dale Schumacher) (07/10/89)
[hjg@amms4.UUCP (Harry Gross) writes...] > In article <381@amms4.UUCP> I wrote: [several leap-year calculations and corrections deleted] > > if (year%4 == 0 && year%100 != 0 || year%400 == 0) > printf("LEAP YEAR!"); > > That test comes from the K & R book, from their date conversion routine > somewhere around page 103 (113?). I should have looked before I leapt :-) Another approach is to use the Julian date to determine if there is a Feb 29th in a certain year. The following is a nice computation for Julian date (from dLibs) which will remain valid far into the future: long julian_date(time) register struct tm *time; /* * Number of days since the base date of the Julian calendar. */ { register long c, y, m, d; y = time->tm_year + 1900; /* year - 1900 */ m = time->tm_mon + 1; /* month, 0..11 */ d = time->tm_mday; /* day, 1..31 */ if(m > 2) m -= 3L; else { m += 9L; y -= 1L; } c = y / 100L; y %= 100L; return( ((146097L * c) >> 2) + ((1461L * y) >> 2) + (((153L * m) + 2) / 5) + d + 1721119L ); } To determine if a given year is a leap year, calculate the Julian date of Feb 28th and March 1st of that year and see if they are 1 or 2 days apart. In addition, since Julian date is a linear count of days, it makes date difference computations much easier. Used with a modulus operation, it also provides an easy way to determine day of the week, like this: t->tm_wday = (jdate + 1) % 7; /* 0=Sunday ... 6=Saturday */ PS. The tricky part is converting back from a Julain date to month/day/year. \\ / Dale Schumacher 399 Beacon Ave. \\ / (alias: Dalnefre') St. Paul, MN 55104-3527 >< ...umn-cs!midgard.mn.org!syntel!dal United States of America / \\ "What is wanted is not the will to believe, but the will to find out, / \\ which is the exact opposite." -Bertrand Russell
jxh@cup.portal.com (Jim - Hickstein) (07/11/89)
>You have the century years backwards! 1700, 1800, and 1900 were NOT leap >years, but 2000 will be. No flame, just a warning: check this algorithm >BEFORE you code it into something that might be around for very long. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here is today's Sermon: :-) The only assumption that can be made about the life of ANY program, ESPECIALLY those little, throw-away things you dash off in a moment of crisis, is this: SOFTWARE IS PERMANENT. Almost certainly, some of your software will outlive you; certainly some of it will outlive your ability to explain it. You cannot know, a priori, what software this will turn out to be. Do prosperity a favor: design for permanence. You may achieve it in spite of yourself. -Jim Hickstein jxh@cup.portal.com ...!sun!portal!cup.portal.com!jxh
jxh@cup.portal.com (Jim - Hickstein) (07/18/89)
> Do prosperity a favor: design for permanence. You may achieve ^^^^^^^^^^ > it in spite of yourself. Oops. Yes, I meant posterity. Several people have pointed this out. I *am* a native English speaker; I guess I just type too fast. :-) -Jim Hickstein jxh@cup.portal.com ...!sun!portal!cup.portal.com!jxh
jms@tardis.Tymnet.COM (Joe Smith) (07/19/89)
In article <061089A1311@syntel.UUCP> dal@syntel.UUCP (Dale Schumacher) writes:
< return( ((146097L * c) >> 2) +
< ((1461L * y) >> 2) +
< (((153L * m) + 2) / 5) +
< d + 1721119L );
I love it! One question though, what in the heck is the 1721119 for?
That many days is over 4000 years. That constant should be -68142 if
you want day 1 to be 18-Nov-1858, right?
--
Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com
McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P,"
San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"