back to article Microsoft Outlook sends users back to 1930 with (very) mini-Millennium-Bug glitch

Microsoft has released a (very) miniature rival to the Millennium Bug into the wild with a glitch in Outlook that takes the user instead back to the 20th century if they seek dates beyond December 31, 2029. Those with long enough memories will recall the Millennium Bug, a feature of software design resulting in two-digit date …

  1. The Oncoming Scorn Silver badge
    Coat

    Collapsing global economy and rising fascism.

    So no real change then - Situation normal.

    1. Totally not a Cylon

      Re: Collapsing global economy and rising fascism.

      There's an acronym for it too:

      SNAFU.

    2. Anonymous Coward
      Big Brother

      "they will land in the future to enjoy floating skateboards"

      Or they could find themselves in "1984"....

      1. Ken G Silver badge

        Re: "they will land in the future to enjoy floating skateboards"

        Thatcher!

    3. MiguelC Silver badge

      Re: Collapsing global economy and rising fascism.

      That paragraph, and the one about contradicting views on the Y2K bug, are filled the kind of subtleties that the old Reg was choke full of and made me want to read it instead of greyer publications but are, unfortunately, getting rarer in current articles

      As others say, bring Dabbsy back!!

      1. Chris Gray 1
        Trollface

        Re: Collapsing global economy and rising fascism.

        Hmm. "choke full" instead of "chock full" perhaps implies you don't like them.....

      2. Anonymous Coward
        Anonymous Coward

        Re: As others say, bring Dabbsy back!!

        You know that survey thing that keeps appearing at the end of articles, asking for feedback on important issues?

        Select other, and then state "bring Dabbsy back!"

        :-)

    4. Michael Wojcik Silver badge

      Re: Collapsing global economy and rising fascism.

      Before clicking the forum link I thought, "I'll bet the very first post is the one that takes the bait".

  2. This post has been deleted by its author

  3. GlenP Silver badge

    Not Just Outlook

    I believe most Microsoft products currently assumes that two digit years from 30 upwards are 19nn, and I doubt it's unique to them.

    Excel certainly works that way, enter 31/12/29 and you get 31/12/2029; enter 01/01/30 and you get 01/01/1930, although for MS SQL 01/01/50 is the changeover date.

    1. An_Old_Dog Silver badge
      Windows

      Y2K & Date Windowing - THIS IS NOT A BUG

      (/me yells into a pillow in frustration, then takes a deep, calming breath) For those of you who were not involved with Y2K testing or remediation:

      There is a limited range of dates expressable using just two digits for the year.

      "Date windowing" is a technique which allows the use of two-digit years. The farther back (in the past) you set the lower bound of the window, the fewer future dates are expressible within in the window. The window is not stretchable. It covers a range of 100 years.

      Microsoft picked what they thought was a reasonable lower bound for their window, and most (not all) other companies used that same lower bound for theirs.

      If you want to express dates beyond 2029, you will have to type in four digits for the year. This is not a bug; it's an inherent limitation using date-windowing where the lower bound of the window is set to 1929.

      Software which will not allow you to type in four digits for the year, or which will not display four-digit years, does have (unremediated) bugs.

      1. Wally Dug

        Re: Y2K & Date Windowing - THIS IS NOT A BUG

        Did there not used to be an option for that within Excel (at least, maybe the other Office apps too) that you could set the "start year"? I've just checked my current version though and I can't find it.

        1. J.G.Harston Silver badge

          Re: Y2K & Date Windowing - THIS IS NOT A BUG

          A common method is a sliding window, eg $thisyear-60 to $thisyear+40 assuming more dates in the past are going to be manually typed in. (Because most of the dates my code flings around go into file stamps, I use 1980-2079.)

          But really, the solution is for the software to scream at the user and refuse to accept manually typed two-digit years.

          1. An_Old_Dog Silver badge
            Alert

            Re: Y2K & Date Windowing

            Sliding date windows: beware!

            Sliding date windows ~might~ be okay for manual data input, but should not be used for programmatic data input, nor for internal calculations. If you use sliding date windows for manual data input, aren't you depending on your users to know the limits of the sliding window, and know that today, the maximum two-digit date they should use is DD-MM-YY? If users don't always correctly remember-and-compensate, they may inadvertantely introduce data errors. This sounds like a recipe for trouble.

            Using sliding windows with a fixed set of programmatic input data will produce output which varies depending on the date when the program was run.

            Using sliding windows in internal calculations wth a fixed set of data will produce output which varies depending on when the program was run.

            I don't want my martgage payments or drug dosages varying based on "stuff".

            1. Anonymous Coward
              Anonymous Coward

              Re: Y2K & Date Windowing

              Programs that output incomplete dates for other programs to consume need to be taken out behind the shed and beaten with a shovel.

              The programmers who *wrote* such an abomination any time in the last 30 years need the same, along with an additional dose of carpet and quicklime...

              Actually storing dates as a two-digit year has been Really Dumb for quite some time now.

        2. david 12 Silver badge

          Re: Y2K & Date Windowing - THIS IS NOT A BUG

          Yes, there is an option, but it's not an 'Excel' or 'Outlook" option, it's a 'System' option.

          On Win7 it's in 'Region and Language" -- which is not intuitive, but it's where you select which calendar you system uses.

          Where it is on Win10 or 11, or 365, I leave as an exercise for the reader.

          1. Geoff Campbell Silver badge
            Windows

            Re: Y2K & Date Windowing - THIS IS NOT A BUG

            It's in the same place in Windows 11 (and presumably therefore in 10, too). It's one of the few remaining things you need to launch the old Control Panel for, there isn't an equivalent in Settings.

            Interestingly, in Windows 11 the default setting is 1950 -> 2049, so dates up to 31/12/49 should fall into the 21st Century correctly.

            GJC

            1. Captain Scarlet

              Re: Y2K & Date Windowing - THIS IS NOT A BUG

              Windows 10 is also 1950

              1. Geoff Campbell Silver badge

                Re: Y2K & Date Windowing - THIS IS NOT A BUG

                Thanks, I didn't have a copy to hand to check.

                GJC

            2. Geoff Campbell Silver badge
              Windows

              Re: Y2K & Date Windowing - THIS IS NOT A BUG

              (Having now checked, Outlook on Windows 11 puts 01/01/30 into 1930, so it looks like it's not honouring the system setting for the date windowing. D'oh!)

              GJC

      2. Dan 55 Silver badge
        Trollface

        Re: Y2K & Date Windowing - THIS IS NOT A BUG

        MS' crime is the window hasn't kept up with the current date, it's probably remained the same in Outlook for two decades.

        This is assuming that the only date windowing happening now is for user input and everything works behind the scenes... I'm sure it does, right?

        Icon is for "depending on who you believe" in the article. They still know how to wind up commentards of a certain age when they want to despite the po-faced new house style (they're turning into Ars Technica...).

        1. Anonymous Coward
          Anonymous Coward

          Re: Y2K & Date Windowing - THIS IS NOT A BUG

          Of course if they changed it from 1930-1940, we would be complaining that anyone aged 80-90 suddenly stopped getting their pension payments as they were now minus 12 years old or whatever...

          A bit of user responsibility is required here

          1. Dan 55 Silver badge

            Re: Y2K & Date Windowing - THIS IS NOT A BUG

            Date windowing should just be for user input at the keyboard where the year is immediately converted and the user can see if the wrong century was chosen. Nobody's going to stop getting their pension at -12 as a result of moving the window.

            But by not moving the window, it will cause problems at around 2030 or so.

          2. swm

            Re: Y2K & Date Windowing - THIS IS NOT A BUG

            My grandfather had a life insurance policy and the insurance company wanted him to cash it in. For tax reasons he didn't want to. Big argument. Seems the age field was only 2 digits and he was over 100.

            Oh well.

      3. Anonymous Coward
        Megaphone

        Re: Y2K & Date Windowing - THIS IS NOT A BUG

        Absolutely.

        Unlike Y2K, where users couldn't enter a four digit year because the database or the data entry screen wouldn't allow it, this is entirely a user problem where users can't be bothered to enter a four digit year.

        If Microsoft wanted to fix it they'd require four digit year entries in Office.

        We'd approve, but the common users would scream bloody murder.

      4. TonyR

        Re: Y2K & Date Windowing - THIS IS NOT A BUG

        Absolutely and not unique to Microsoft. LibreOffice does the same, which is recognised as Good Practice.

        1. Martin Gregorie

          Re: Y2K & Date Windowing - THIS IS NOT A BUG

          IMO the sliding date window is ONLY acceptable for general use if entering a two digit year always means the current year: if you want to input a date in any other year, then enter four digits. This assumes the system is a financial one and is only dealing with precisely known dates that are close to the present, AND that an European/American style calendar is being used.

          Outside financial circles the ways a date is represented and its (implied) accuracy can vary widely.

          I once worked on a music-related system that dealt with dates that, amongst other things, needed to record the date when a piece of music was written or when a composer was alive. As a result it had to deal with dates ranging from from 55BC to the present and with varying degrees of accuracy ranging from "11th century", i.e. some time in that century, up to and including exactly known future dates, such as the projected date of a concert. Needless to say, in this system every date needed to include a code indicating its accuracy and its required format when it was being entered or displayed.

          1. Doctor Syntax Silver badge

            Re: Y2K & Date Windowing - THIS IS NOT A BUG

            If the current year is meant then a day and month should be sufficient. If provision is made to enter a 2 digit year then the sensible default is to that closest to the current year which is what the user is most likely to expect.

            Historical dates are a nightmare. E.g. the archivist classified something as "Early C14th" but looking at it I suspect it could be before another dated in the 1290s and none of the witnesses who are found in other, dated, documents are exclusively C14th.

        2. Doctor Syntax Silver badge

          Re: Y2K & Date Windowing - THIS IS NOT A BUG

          I've used LibreOffice entering dates - as 4 digits - back to the C12th. I have no problem with using 4 digit formats. But if the year is set to 2 digits the default should be what a user might find most reasonable and I doubt a date almost a century ago compared to one a few years ahead is not likely to be considered reasonable.

          This might have been reasonably considered Good Practice back in 1999 but I can't imagine anyone being able to put forward a cogent argument for its being that almost a quarter of a century later.

    2. This post has been deleted by its author

    3. PBuon

      Re: Not Just Outlook

      .NET Framework and Core behave like this when parsing a two digit year.

      Would have expected Core to be **50.

      What am I saying? I didn’t expect that at all.

  4. xyz Silver badge

    Off topic but...

    Can you get rid of that bloody questionnaire? I filled it in hoping it would then vanish but it's still stalking me page after page. TIA.

    1. Mike 137 Silver badge

      Re: Off topic but...

      If you mean the "cookie consent" banner, it's actually unnecessary as it hides a link at the bottom of the page (Your consent options that should do the same thing. The myth that cookie banners are required by law is actually a massive con. The law requires consent to be sought for non-essential trackers (including cookies) but it's actually unlawful to try and coerce consent by interfering with access to a site (e.g. by use of intrusive banners). The problem is that if there were just a passive link, nobody would follow it and agree to non-essential trackers, so the industry has decided to make it annoying so we are temped to clock through thoughtlessly, giving them the supposed right to use non-essential trackers. I say 'supposed' because it's actually breaking the law. It's notable that the banner you are apparently objecting to is much larger than strictly necessary and obscures the foot of the page content.

      The problem though is that the regulators don't really give two hoots about this kind of law breaking, to the extent that the UK govt. is trying to remove the consent requirement on the ironic basis that people don't like the essentially illegal cookie banners. So because people object to businesses breaking the law by coercing consent in order to track us, we're going to make what they're doing lawful by allowing them to track us without consent (so they won't need to use the annoying banners any more).

      1. drand

        Re: Off topic but...

        I like your rant but I think the poster is referring to the 'What are the biggest tech-related initiatives impacting your organisation right now?' inline panel that appears at the bottom of every article, whether you've answered it or not.

        Maybe it gets blocked by certain ad/tracker blockers, but I get it here at work.

        1. Anonymous Coward
          Anonymous Coward

          Re: Off topic but...

          Sounds like a great way to get a load of unwanted noise/garbage responses messing up your survey.

          Is there any way for them to intelligently filter out random selections hammered in by people under the (mistaken) impression if they do so it'll go away, or by those who just dislike the thing full stop and want to mess it up?

          1. Anonymous Coward
            Anonymous Coward

            Re: bloody questionaire

            .. as commented above, perhaps give response Other/ "bring Dabbsy back!"

    2. TeeCee Gold badge
      Alert

      Re: Off topic but...

      I'm sure the vultures are still trying to work out a way of getting it to follow you around via electronic advertising hoardings, destination boards and the like.

  5. katrinab Silver badge
    Alert

    Can confirm, the millennium bug was mostly "an overblown scam to suck money into the tech industry", peddled by people who mostly didn't know the difference between a bug and a virus, and had magic snake-oil fixes for sale.

    Because obviously if my 1990s electromechanical washing machine thinks it hasn't been invented yet, it is going to spew water everywhere and spontaneously combust.

    1. drand

      Maybe so...

      But my dad caning overtime on late 90's millennium bug ERP projects paid to put me through university, so I'm not complaining!

    2. IGotOut Silver badge

      No it wasn't overblown.

      It was because people like me spent hundreds and hundreds of hours making sure everything DIDN'T go titsup.

      Its like saying aircraft design is overblown, because all the planes I see fly just fine.

      1. 45RPM Silver badge

        Me too - and, having fixed it, pulled all nighters around the new year because management weren’t 100% convinced that our fixes worked.

        Luckily they did - although the downside is that we now have to put up with conspiracy theorists claiming that it’s all a scam.

        I now work in a field adjacent to medical research and I see the same dimwits denigrating the efforts of my colleagues by saying that the Covid vaccine is a scam.

        Same dimwits, different decade.

        1. Doctor Syntax Silver badge

          Also politicians saying the experts were wrong & we didn't need lockdowns.

      2. Anonymous Coward
        Anonymous Coward

        In 1998 I was part of a team of 70 in the UK working on Y2K fixes for combined banking & insurance systems created in the 1970s. Plus a software house in India working on the simpler fixes. Plus an automated s/w updating tool running in the US for the easy-to-spot issues. Plus a team of people working every night to fix crashes caused by having birth dates before 1900 and policy expiry dates after 2000 on a system that had been written with 2-digit dates in many hundreds of different fields across a similarly large number of programs. For that particular business, it was a potentially terminal issue that had to be fixed and tested well before 31/12/99.

        1. An_Old_Dog Silver badge

          Banking/Insurance

          Kudos for your efforts, but your higher-level management sucked for not having started the Y2K work earlier.

          Properly-done, Y2K testing and remediation would not be a down-to-the-wire finish. (Our management sucked, too. If we'd started a year earlier, we would have finished "comfortably" on time, rather than "barely" on time. On the plus side, in 1999 I made more money from overtime than from my normal pay.)

          1. A.P. Veening Silver badge

            Re: Banking/Insurance

            Kudos for your efforts, but your higher-level management sucked for not having started the Y2K work earlier.

            It should have been started earlier, but management did suck big time. In 1991 I got a negative comment for using four digit years in programs I wrote during my education as programmer. I countered with two questions:

            1) If this were for real instead of education, what would be the expected lifetime of the program?

            2) If this were for real instead of education, what would be the chance of the program being used beyond that expected lifetime?

            The answer to the first question still (marginally) allowed for a two digit year, the answer to the second was embarrassed silence.

            As a bonus, they were impressed by my correct leap year check using a single division by four.

            1. Dan 55 Silver badge

              Re: Banking/Insurance

              I understood the rule to be this:

              / 4 = leap year

              But / 100 = non-leap year

              But / 400 = leap year

              If it isn't, someone had to tidy up my Y2K work after I left.

              1. Bill Gray

                Re: Banking/Insurance

                A simple divide-by-four will work between 1900 March 1 and 2100 February 28. Which might have led the above to be expanded to...

                3) What's the likelihood this will be used after 2100 February 29?

                The nature of the assignment isn't mentioned, but if it involved birth dates... in 1991, my then-100 year old grandfather, and many others born before 1900 March 1, still walked the face of the earth. If it involved hundred-year mortgages, there could have been problems nine years later, on 2000 February 29.

                1. A.P. Veening Silver badge

                  Re: Banking/Insurance

                  I first checked if the last two digits were zero. If that was the case, I moved the first two digits to a another variable, if it wasn't, I moved the last two digits to that same variable. Division of that variable by four would indicate whether it was a leap year or not. That method works between 15-10-15821) and 28-02-40002).

                  1)Or whatever date was locally used for the conversion from the Julian to the Gregorian calendar

                  2)Next exception, if the program is still in use when that becomes relevant, they are welcome to recall me by that time.

                  1. Dan 55 Silver badge

                    Re: Banking/Insurance

                    It's a clever enough solution alright, but is it understandable 2000 years later when they're debugging it?

                    After all, films tell us the future will be built on old code.

                    1. A.P. Veening Silver badge

                      Re: Banking/Insurance

                      If they don't understand COBOL anymore at that time (and the program still is in use), they are more than welcome to recall me, but until they do, it is not my problem.

                  2. call-me-mark

                    Re: Banking/Insurance

                    Not sure I understand why it shouldn't work for the year 4000 and after? 4000 will still be a leap-year won't it?

                    1. PBuon

                      Re: Banking/Insurance

                      I think we leap 1000 years on 4000.

                    2. A.P. Veening Silver badge

                      Re: Banking/Insurance

                      Not sure I understand why it shouldn't work for the year 4000 and after? 4000 will still be a leap-year won't it?

                      The year 4000 won't be a leap year, next exception as I wrote. The rounding errors on all of those decimals will accrue to a whole day (too much) by that time. But it is sufficiently far away none of us will have to deal with it (unless we are recalled ;) ).

                  3. swm

                    Re: Banking/Insurance

                    1900 was not a leap year.

            2. J.G.Harston Silver badge

              Re: Banking/Insurance

              When I started programming in the early 19*80*s it was drummed into us not to use 2-digit years. I'm gobsmacked that educators (even worse, I'm guessing at *university* level?) were actually actively forcing people to use 2-digit years IN THE 90S!

    3. An_Old_Dog Silver badge

      Y2K - not *just* snake oil

      Y2K was not just snake oil. Working at a teaching hospital, we discovered Y2K bugs in life-affecting software -- software which our vendor had told us had been successfully Y2K-tested.

      1. Terry 6 Silver badge

        Re: Y2K - not *just* snake oil

        It's the just that is the issue there. As part of a local authority teaching team we had to use a chunk of our limited budget to get our lap tops Y2K tested. Even though they were standalone machines, no networking and not system critical in any way.

        But paying for the test was compulsory. For all of them And that was just us. I'm sure the same waste of money was replicated in lots of places. Everything had to be certified. There was no risk assessment element.

        1. An_Old_Dog Silver badge

          Re: Y2K - not *just* snake oil

          Sounds like someone higher-up on your management food chain bought the snake-oil.

      2. Michael Wojcik Silver badge

        Re: Y2K - not *just* snake oil

        we discovered Y2K bugs in life-affecting software

        Indeed. At the time, someone posted to RISKS (if memory serves) an account of fixing software for a dialysis machine that went into cleaning mode if the date 9/9/99 was entered. That's another variant of Y2K bug – an assumption that your software won't be used after a not-far-distant date – which would have killed people if not corrected.

        People routinely underestimate how long their software will be in use. I support a commercial software package that was last updated about two decades ago; we have a handful of customers who are still using it. (That is, I officially provide development support for it. We haven't actually had any support questions about it in years, and even then they were generally "we moved this to a new machine and no one still working here has any idea how to adjust the configuration".) Last year I got rid of a VHS VCR that only supported two-digit years, so it no longer had the correct day-of-week in its display (which I didn't care about, but it's another example).

        Customers occasionally give us pieces of their application source code to help diagnose some obscure problem, and it's not unusual to see change dates from the 1980s or even 1970s.

    4. MiguelC Silver badge

      The 31/Dec/1999 night I was on duty, after a year and a half working on that project for a large bank.

      At around 1 AM I went to the nearest ATM and checked my balance and latest account movements (my account was not with the bank I was working for). There was an interest credit of around the equivalent of 3000€. Resisting the urge to spend it there and then, I went back, showed the slip to my co-workers and pondered on what would happen from there on. At 8 AM, after an uneventful night on the job, I went down and checked my balance again. Without a trace of that earlier payment, it now showed the correct and, unfortunately, much smaller interest deposit...

      Someone's night was indeed a lot more eventful than mine ;)

    5. Doctor Syntax Silver badge

      the millennium bug was mostly "an overblown scam to suck money into the tech industry"

      It's not so long ago that I posted this here, as I have done a few times before but obviously it needs to be repeated:

      I had a client who had a non-Y2K compatible version of their accounts S/W. Their old alleged hot standby server (also previously commented on) wouldn't run the newer version so both servers were replaced and UAT completed to the accountants' satisfaction. We planned to cut over between Christmas & New Year. The accountants chickened out and wouldn't let us until they'd closed out 1999 accounts in mid January. It was a torrid couple of weeks with the vendors dialling in (a modem on a serial port!) several times each week to fix the data.

      Yes, Y2K really was a genuine problem.

    6. Anonymous Coward
      Anonymous Coward

      Oracle Forms

      In the late 1990s I was working with Oracle Forms (kids, ask the oldest person in your IT department) and I can state for a fact that we had to do a lot of work and even more testing to fix a slew of Y2K bugs. Without this work, many 1000s of applications in every field, affections 100s of thousands of end users, would have been impacted.

      Most basically, we implemented customer-settable date windowing including a runtime parameter for the base date. But we also did a laundry list of other fixes, changes, and user options including adding support for the RRRR date format. And we had to deal properly with data from Oracle 6 databases.

      And even then, many customers had to do work themselves e.g. to fix form layouts with field expansion to allow 4 digit dates; or to correct date arithmetic and related logic.

      So yeah, anybody who says it was a scam is flaunting their ignorance, and El Reg is really not a great place to do that.

  6. Mike 137 Silver badge

    Yet another example

    Yet another example of why automatic updates are a bad idea - particularly stealthy updates.

  7. Henry Wertz 1 Gold badge

    Not a glitch

    Not really a glitch -- this is (AFAIK) documented behavior within the Microsoft Office products, they picked xx30 as the cutoff probably arbitrarily, but back in like the 1990s, when xx30 would be pretty far from the current year in either direction. Solution? Use a Y2K-compliant date! If you're going to put in a non-Y2K complaint year, they have to do something after all -- the reasonable thing may be to put the current millenium and century on there, except then people would be crying up a storm when they put in "1/1/99" and get 2099 out (... for a few more decades, then they could complain that when they put "1/1/01" it's giving them 2001 instead of 2101).

    Of course, for compatibility with existing files, it will probably have to ALWAYS treat 00-29 as 2000-2029, and 30-99 as 1930-1999, even when it's 2040. After all, otherwise all your existing files with improper dates would suddenly have the date jump ahead 100 years.

    1. Doctor Syntax Silver badge

      Re: Not a glitch

      FWIW LibreOffice and OpenOffice Calc are bug-for-bug compatible with Excel in this respect. It's noticeable that the formatting dialog gives 1999 as an example. It's time they caught up on that and I'm disappointed they don't use a sliding window.

      1. Dan 55 Silver badge

        Re: Not a glitch

        At least LO fixed Excel's "29th of February 1900" bug.

        Legend has it it was a deliberate bug so Excel would calculate dates the same way as in Lotus 1-2-3. In order to gain market share, it apparently was more important to get things wrong the same way the market leader did.

    2. Spazturtle Silver badge

      Re: Not a glitch

      Doesn't Excel destructively format data? So when you type "1/1/30" it actually changes the value of the cell to "01/01/1930" which means there would be no incompatibility with changing the date window in the future as it would only affect new data that is entered.

      1. Nick Ryan Silver badge

        Re: Not a glitch

        Yes, Excel regularly destructively formats data. Import data including large numbers or number fields with leading zeros and Excel will merrily go ahead destroy the data with no recourse other than to recreate/reimport the data...

  8. Mike Lewis

    I fixed my first Y2K bug in 1988

    I was working on air conditioning control software when I found it and thought "Buildings stay up for a long time. There's a good chance this program will be running after 2000."

    I keep wondering if I should have told someone.

    1. claimed Silver badge

      Re: I fixed my first Y2K bug in 1988

      Sadly also a bit too late to put a trademark on the 'Mike Air Max Date' bug

    2. Anonymous Coward
      Anonymous Coward

      Re: HVAC

      Hey, me too. As a student in the mid-1980s I had a summer coding job at Satchwell Control Systems and one of the things I wrote was for standard time/summer time switching. And I can say for a fact that unless somebody else fixed it, that code (a) was in buildings including at least one major hospital at the turn of the millennium and (2) would not have worked properly after that time.

  9. Anonymous Coward
    Anonymous Coward

    Didn't expect their software to last that long

    Was it Windows o8 or Office 98 that was discovered not to be able to handle dates past December 31st 1999 correctly on initial release??

    1. Anonymous Coward
      Anonymous Coward

      Re: Didn't expect their software to last that long

      Office 95 and Office 97 certainly had what I would consider a more serious bug than 2 digit years.

      The ability to copy/read password protected documents in seconds without the need for a password or anything other than Office itself.

      Word documents could be compared to a blank document and give you all the contents of the password protected file. Simply because everything was different.

      Showing a very large hotel admin office that thousands of documents of their clients from conferences I could easily read including some of my companies competitors caused panic. Especially as even back then they had several back doors installed that were able access to the same files remotely.

      For the record rather than open a competitors file I had the secretary create a new one and I then opened it, cut and paste it in to a new document so it looked the same without demonstrating how I did so. My ethics and mission was to get their 'IT' support to do something about it and not blame network issues they had on my companies equipment.

      Thankfully MS sorted that issue out in Office. I never did find out if the hotel decided to delete all the documents they kept from previous conferences or not as I was never asked to do a call out on our equipment there.

  10. Anonymous Coward
    Anonymous Coward

    Now that's subtle shade

    "Outlook sends the user back to 1930, where they may have to deal with a collapsing global economy and rising fascism."

    I know it's been commented on above, but this was a masterpiece of under-the-radar comment. If I wasn't a coward I would be able to select the coffee-spattered keyboard icon.

  11. TeeCee Gold badge
    Facepalm

    AHEM!

    To save memory, early coders used the shortcut,

    Depending on the language you were using, you often had no choice. More than a few had all the built in dates (e.g. today's date) and the handling for conversions as six digit date only.

    1. JacobZ

      Re: AHEM!

      Many early databases also stored the date as two digits (or at least defaulted to that - Oracle 6 and earlier, I think?). Consequently, you ended up with windowing logic in the application itself in order to slide the 100 year range available to the coder to an application-appropriate window.

      1. A.P. Veening Silver badge

        Re: AHEM!

        Many early databases also stored the date as two digits

        That is a nice trick, storing a date as two digits. Can you please explain that technique as I need at least five digits for a date when I use Julian date format or weeknumber and daynumber format, in both cases with two digits for the year.

        On a related note, I know of at least one person, who managed to store full dates in six digits by conversion to number of days from a (arbitrary) base date. That gives a window of 2 * 2,740 years.

        1. Nick Ryan Silver badge

          Re: AHEM!

          The dates were often stored in the databases as character strings. Usually in a local and non-transportable format of course... why use the international standard YYYYMMDD (or YYMMDD) which is easily sortable when a local standard that is not easily sortable can be used instead?

          Other than legibility by developers who are unable to understand YYYYMMDD formatted dates, there were few database advantages to storing the date in text form and the text form even allowed invalid dates to be recorded, which causes no end of problems when encountered. However the comparison gets a bit muddied depending on how the date is actually stored in the database, dates are usually stored as:

          • a one or two byte year, single byte month and single byte day of month, summing to three or four bytes of storage.
          • a six or eight character string, which is six or eight bytes of storage
          • the number of days from an arbitrary starting point, which is usually a four byte integer but can easily be represented with a three byte or even two byte integer depending on requirements

          Where storing dates in a textual form has an advantage is where the developer just takes the raw character string and throws it out to the user, possibly with separators put into the character position extracted date components.

          The alternative is that, as noted by the previous poster, a date is recorded in the database as a numeric value with an offset from a given arbitrary point in time. This is much more efficient by way of data storage, dates cannot be an invalid date and day based date mathematical operations are much simpler. The major downside is translating such a numerical date into the date components of year, month and day can be computationally quite expensive and when looking at the raw data the date cannot be easily seen. Converting character strings into the date components is simpler but the values must then be checked for validity which when compared to an efficient number to date conversion algorithm makes the translations quite similar processing wise.

          Date manipulation such as adding or subtracting months is tedious regardless of the underling format due to the variable month length, let alone leap years and even adding or subtracting years is tedious for similar reasons as 29th February is only valid every on a leap year.

  12. Pirate Dave Silver badge

    "Microsoft's Outlook glitch is nothing like that but is a tad embarrassing for the global software giant,"

    Doesn't "embarrassment" imply shame? Which we know Microsoft has none of...

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like