Microsoft codes leap year bug into Exchange 2007 If Steve Ballmer turns up dead this week, you can bet he was killed by those 7000 leap year babies. As the international Honor Society of Leap Year Day Babies continues to gripe about the 25-year-old leap year bug infesting Microsoft Excel, word has arrived that Microsoft Exchange doesn't understand leap years either. On …
Anyone who has looked at the mess which is OpenOffice/Excel date compatibility, will understand my reluctance to ask for a version of Excel which is only 'compatible' with the old Excel date system.
Frankly, I need a version of Excel which reports correct dates in 1900 like I need a version of Excel reporting correct dates on the 'old calender' or c 0001.
What I need and want is a version of Excel which is the same as all other versions of Excel.
Oh dear this could be expensive. If the bank doesn't know how many days are between transactions they could apply the wrong interest. The funny thing is a loan is a legal contract between the client and the bank. So if they charge you the wrong amount of interest that could void the contract, given the right judge. I wonder if any of the 7000 are judges?
It is depressing that there is really nothing new here. *Every* time there is a leap year, bugs in handling the February 29th are reported (just comb the back issues of the venerable comp.risks mailing list). The rules of the Gregorian calendar aren't really that difficult to grasp, they are not trade secrets, and they have been available for centuries. Tells a lot about the incompetence of most programmers.
That is when the UK switched from Julian to Gregorian calendars to standardise with Europe. September had only 19 days. Tenants paid a full month's rent, employees received pay for 19 days and christians got upset because 11 days had been taken from their lives (The date of their death is supposed to be written in some book. Imagine the chaos is they believed that heaven's bureaucracy used excel).
Sorry, but I would prefer a version of Excel that gave me correct results. Actually, I prefer OpenOffice...
And good luck getting a version of Excel which is compatible with all other versions. MS wants you to buy the newer version so they make sure that Excel only loads files created with the last two or three versions. OpenOffice is much better, they load all kinds of files...
"Actually, I prefer OpenOffice..."
Actually I still prefer other programs (not even suites) and use OO under sufferance - less than others but I still find the fundamentals of word processing in OO and MS-O incomprehensibly confused.
I am used to an entirely frame based wordprocessor, with entirely character-based formatting. It is called DeScribe, it was built for OS/2 and still runs faster on eCS, and does almost all I want.
I would prefer that the builders of OO just do the Save As stuff compatible with MS-O and then go and do the rest as logically and as user-friendly (yes, I know, hatcheck by the door) as possible.
I believe this business of staying as close as possible to MS-O in both UI and function is crippling the take-up of OO.
My iPAQ with Windows Mobile 2003 went haywire after midnight on 29th Feb as it suddenly decided that it was 1st March 2035. It then reminded me of 27 years worth of overdue appointments. It took me two soft resets with accompanying date changes before it finally came back from the future. A friend with a Windows Mobile powered phone had a similar experience. It makes you proud to serve doesn't it?
As a student of medieval history, I couldn't use Excel (Office X for Mac), as it thinks the world began in 1900, and does not recognise earlier dates as dates.
Numbers (part of iWork on the Mac) lacks many features of Excel, but if I type 28 Feb 1260, it correctly tells me that this was a Saturday, and that the next day was 29 Feb. It can't be that difficult to get it right.
@John Angelico
"I believe this business of staying as close as possible to MS-O in both UI and function is crippling the take-up of OO."
Spot on, IMHO, the fervour to match MS Office or any M$ product merely makes competitors look like 'also rans'. They should be innovating which brings me neatly to...
@Richard Cassidy
"Numbers (part of iWork on the Mac) lacks many features of Excel, but if I type 28 Feb 1260, it correctly tells me that this was a Saturday, and that the next day was 29 Feb. It can't be that difficult to get it right."
Absolutely. And very nice UI's for all the iWork suite. (Once you use Keynote you won't use Powerpoint again... )
"The rules of the Gregorian calendar aren't really that difficult to grasp, they are not trade secrets, and they have been available for centuries."
Indeed. I'm amazed too. In fact, I was so amazed that I googled for "C++ code for leap years". OMFG, was *that* a depressing set of search results.
If you want revolutionary on OS/2, look at Mesa/2 - now *that* was a spreadsheet. Load and manipulate 100,000 rows? No problem. Excel wasn't able to do that until one release back, neither was 1-2-3.
Describe was technically extremely impressive, and the print output was lovely. Unfortunately the interface was, IMO, vastly inferior to Ami Pro and Wordpro.
Even as an ardent OS/2 user at the time and owning a load of legit OS/2 software including Describe, I wrote my dissertation in AmiPro running under WinOS/2 (because OS/2's Amipro was buggy to the point of unusability). I subsequently bought the Open32 based Smartsuite for OS/2. It wasn't as fast, or as technically impressive, but the interface was vastly superior to Describe.
Are you sure your Mac is doing this "correctly"? The trouble is that in 1260 the Julian and Gregorian calendars differed by 7 days, so we can't tell from what you wrote which of the calendars the program is using.
In general you have to specify which calendar you're using because different countries adopted the Gregorian calendar at different times. However, a historian would not normally want to use a Gregorian date in 1260.
Check that your program knows that 28 Feb 1360 (Julian calendar) was a Friday!
Hell I'm still using Lotus 123R5 on odd occasions when Open Office won't do the job and I never got any version of Excel to do the same tasks that are trivial in 123. Similarly with Wordperfect 6.1 which, with the aid of "reveal codes" and search and replace on specific format codes can manipulate text files in (at least to me) extremely useful ways - Word won't EVER come close but even if it did I'm not giving the opportunity to Microsoft ever again.
Why is not recognising 2008 is a leap year (very simple its /4) less ridiculous than recognising 108 years ago was not a leap year as despite being /4 is /100 but not /400. Not many people are interested in 1900 except for curiosity. But not being able to set up email for a whole work day could cause actual loss.
Numbers is using the Old Style (Julian) calendar for the thirteenth century - as it should, since New Style did not begin until October 1582, for those who followed Gregory XIII's bull, and much later for Protestant countries. I haven't bothered to check when the program makes the transition to New Style, as I'm not interested in stuff as recent as the sixteenth century.
And indeed it gets 28 Feb 1360 right.
Why the H! date/calendar functions aren't part of the OS, so that you can be certain that ALL programs behave similarly?
(On Windows, that would usually mean getting leapyears on years numbered 1, 5, 9, 13, 17 and so on... )
Stuffs his Psion S3c in his coat pocket and heads for the hills...
I never understand this stuff about leap years. Type in the date, add 1 in the next column. Result, correct date. Though I have no idea whether the medieval dates are actually "correct" because the calendar changes makes this an interesting challenge of definitions I expect.
No such excuse for confusion in the recent past ( say 200 years ) I would have thought.
Friday 28 February 1360 Saturday 29 February 1360
Wednesday 28 February 1900 Thursday 1 March 1900
Monday 28 February 2000 Tuesday 29 February 2000
No, wait. OOo is being incompatible with MS Office.
What we need is some kind of ISO standard for this ...
... or maybe two, or three.
Where I'm working they have a payments processing application called Paybase, from a company called Bottomline Technologies (yes really). Last Friday it wouldn't process anything because it believed the 29/2/2008 was an invalid date.
The app was fixed after a call to Tech Support who directed us to download an updated DLL from their website. However I noticed that there were versions for something like 5-6 different versions, so exactly how long had it been there?? And just how stupid do you have to be in the first place to write a function that validates dates but doesn't handle leap years??
Finaly I work out their business plan. if you find a bug and you know there is going to be many bugs, put it out there. As time goes on people will get numb to idea that we dont produce quality software and it will become a Feature.
Yes this is a Feature of our software. Its not a bug! If you find that hard to swollow we will just say its not supported anymore so we dont have to wast time coding more than we have to.
What a bunch of loosers! SO LAZY! Shoddy buggy low quality workmanship!
Our trouble ticketing system (It was purchased not built but also not named to avoid libel charges) had its own date calculation routine because [insert company name here] didn't want to be held hostage by someone else screwing up the new(ish) daylight saving changes here in NorAm. I'm assuming they did this correctly but will find out for sure this weekend. However, the same programmers forgot that we are in a leap year and it took several hours for us to install a fix and bring up the application before we could log the problem.
Sigh....
@Fraser
Given the accuracy of the Bible with numbers (pi anyone...?) I don't think that you're in any position to suggest a "better" software package for heaven, does the 35 odd years means you only counted every other one?
@Seán
Interest in banks is calculated on 360, 365 and 366 years depending on the where you are in the world, so typically people can pay more during a leap year.
I suspect that most banks aint gonna be using excel to work out how to charge their customers!
Time is like... relative anyway man.
"Why the H! date/calendar functions aren't part of the OS, so that you can be certain that ALL programs behave similarly?"
First answer: They are, but a long time ago, when the OS was small, they weren't, so applications had to do it themselves and some got it wrong and so to remain compatible, later versions of those applications had to avoid the pre-packaged, correct, OS version of the function and use a carefully crafted turd instead. (That's what MS are claiming for Excel. It has some merit IF you believe that people have worked around the old bug in such a way that their workaround would in turn be broken by fixing the bug. Windows is full of such depressing "compatibility" because the majority of Windows apps are closed source and so end-users can't just fix and recompile them.)
Second answer: They are, but you know the old saying: "You can bring a programmer to existing code, but you can't make them call it." As I suggested in my previous post, if you google for code to perform the leap year test you will see hundreds of people who have polished and published their very own version. I haven't made a survey, but I suspect that a sizeable minority are actually wrong. It's really sad.
When all the fuss about the Y2K cataclysm^H^H^H^H^H^H^H^H^H armageddon^H^H^H^H^H^H^H^H^H^H inconvenience was going on, some of us were feeling particularly smug: in the 70s I was writing code for a quality control department that correctly implemented 4-digit years and was therefore Y2K compliant, but also correctly identified leap years and centuries - it wasn't going to stop finding dodgy tractor components just because it was 29/02/2100! COBOL? COBOLOX! This was on a departmental mini (Wang 2200 T3) using BASIC. It shows that the quality of the final software product depends less on the tool you use than the incompetence of the tools doing the writing.
M$ take note.
"That is when the UK switched from Julian to Gregorian calendars to standardise with Europe. September had only 19 days. Tenants paid a full month's rent, employees received pay for 19 days and christians got upset because 11 days had been taken from their lives"
What do we want?
- Eleven days back!
When do we want them?
- ...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
