From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,92471489ebbc99c6 X-Google-Attributes: gid103376,public From: mfeldman@seas.gwu.edu (Michael Feldman) Subject: Re: Y2K Issues Date: 1998/10/25 Message-ID: <710nnc$jop@felix.seas.gwu.edu>#1/1 X-Deja-AN: 405049299 References: <362B53A3.64E266AB@res.raytheon.com> <362B8D2F.802F42E6@lmco.com> X-Trace: fozzy.nit.gwu.edu 909369864 128.164.9.3 (Sun, 25 Oct 1998 21:44:24 EDT) Organization: George Washington University NNTP-Posting-Date: Sun, 25 Oct 1998 21:44:24 EDT Newsgroups: comp.lang.ada Date: 1998-10-25T00:00:00+00:00 List-Id: In article <362B8D2F.802F42E6@lmco.com>, Howard W LUDWIG wrote: [snip] > >[Note: The fully general rule for leap year is that Year is a leap year >if and only if > (Year mod 4) = 0 and > ((Year mod 100) /= 0 or (Year mod 400) = 0).] > Indeed. As it so happens, I just saw this juicy bit of news: According to "PC Week", issue of 10/19/98, Microsoft's SQL Server 6.5's task manager refuses to recognize Feb. 29, 2000 as a valid date. Apparently Microsoft's programmers never learned the real rules for leap years - a year divisible by 400 _is_ one. Microsoft has acknowledged the bug and will fix it in a "service pack" (Microsoft jargon for a patch). Unlike the Y2K "problem", which is caused by the unintended consequences of an old but intentional engineering decision (2-digit years in the days of expensive storage), the leap-year bug is a _bug_, and is, apparently much more widespread than just this Microsoft case. In scouring code for the 2-digit problem, they are discovering the bug as well. Amazing. Where did these people go to school? Mike Feldman