Microsoft's Azure service toppled by garden-variety leap-year bug
|
|
|
Comments (10)
Now we know the limits of 'plays-for-azure'.
It fits their new logo; even outside of Window Microsoft is still being a pane.
Bad pun! No cookie!
Not Garden Variety: Microsoft Speciality
Leap year and Daylight Savings Time bugs are *not* Garden Variety for Microsoft: they're a Microsoft specialty. Until Windows XP, you couldn't really count on your Windows box handling the Spring Forward, or the Fall Back. The OOXML "standard" for Excel has enshrined a leap year bug: http://www.robweir.com/blog/2006/10/leap-back.html
Windows: a special case, wrapped in an exception, bundled inside of a custom hack job.
Windows: a special case, wrapped in an exception, bundled inside of a custom hack job.
My favourite is still the Microsoft 32-bit clock/timer bug, which meant that Win '9x (and others?) simply could not run any longer than 47.9 days. I understand this made trouble for the occasional air traffic control center.
But the main reason I like it so much is there used to be so many Windows fanbois on ZDNet and similar sights, who swore up and down that they had uptime stats running over three months, over 6 months, sometimes even (with solid admin skills, careful set-up, selective application choices and judicious control over patching) eight, nine or ten months...
Of course, these claims were entirely bogus.
PS: Technically, Linux had a somewhat similar bug, that meant Linux systems would never report an uptime over 497 days (the Linux kernel clock ticked at 100 Htz, rather than 1000 Htz) -- but this bug didn't crash the system or harm its smooth operation, so the system could actually run longer, it just didn't report a higher number when queried for its uptime.
But the main reason I like it so much is there used to be so many Windows fanbois on ZDNet and similar sights, who swore up and down that they had uptime stats running over three months, over 6 months, sometimes even (with solid admin skills, careful set-up, selective application choices and judicious control over patching) eight, nine or ten months...
Of course, these claims were entirely bogus.
PS: Technically, Linux had a somewhat similar bug, that meant Linux systems would never report an uptime over 497 days (the Linux kernel clock ticked at 100 Htz, rather than 1000 Htz) -- but this bug didn't crash the system or harm its smooth operation, so the system could actually run longer, it just didn't report a higher number when queried for its uptime.
> I understand this made trouble for the occasional air traffic control center.
The universal reaction I encountered when that bug was announced was "How did anyone ever keep their system up that long, anyway?" :)
The universal reaction I encountered when that bug was announced was "How did anyone ever keep their system up that long, anyway?" :)
y2k ... anybody?
lessons not learned in blood are soon forgotten...except if you are Microsoft, then, it doesn't matter.
Don't worry, there will be a patch put into Windows to accommodate this, just like the 1900 bug in Excel.
@BR -
Yes, I understand the patch has already been tested and works like a champ, except on March 29, April 29...
Yes, I understand the patch has already been tested and works like a champ, except on March 29, April 29...
I wonder how bad their handling of the Hebrew/Jewish calendar is. it's a lunar calendar with a leap month. In leap years the entire month of Adar is repeated :) Oh, and yeah, there is FOSS software for the Jewish calendar (libhdate, ghcal, hcal, etc...) that works brilliantly and has done for years.
NIH == Not Invented Here? or, Not In Hebrew?
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
