Re: Any leap year issues caused by Ada yesterday?

[Shark8 <onewingedshark@gmail.com>]

On Monday, March 5, 2012 5:07:29 AM UTC-6, tonyg wrote:
> On Mar 1, 1:06 pm, Georg Bauhaus <rm.dash-bauh...@futureapps.de>
> wrote:
> > News travels the wires of the internet telling us about MS Azure outages
> > in several places. These were seemingly caused by a piece of software
> > handling calendar dates involving February 29, 2012.
> >
> >  Which makes me think, presuming it is as simple as it looks,
> > is there a software setup that prevents this kind of damage by
> > definition?
> >
> > (The bigger companies are too big fail just because of a software bug,
> > even if it is of the ravenous bugblatter beast of Traal kind.
> > Maybe a bug that was fixed is even generating attention.
> > But it might help the businesses surviving only if such things do not
> > happen ... again.)
> >
> > From [1]:
> > "Yesterday, February 28th, 2012 at 5:45 PM PST Windows Azure operations
> > became aware of an issue impacting the compute service in a number of
> > regions.  The issue was quickly triaged and it was determined to be caused by
> > a software bug.  While final root cause analysis is in progress, this issue
> > appears to be due to a time calculation that was incorrect for the leap
> > year. Once we discovered the issue we immediately took steps to protect
> > customer services that were already up and running, and began creating a fix
> > for the issue.  The fix was successfully deployed to most of the Windows
> > Azure sub-regions and we restored Windows Azure service availability to the
> > majority of our customers and services by 2:57AM PST, Feb 29th."
> >
> > http://blogs.msdn.com/b/windowsazure/archive/2012/03/01/windows-azure...
> >
> > via
> >
> > http://www.forbes.com/sites/ciocentral/2012/02/29/microsoft-windows-a...
> 
> Personally I deal with it by using the ada.calendar package rather
> than writing my own. I hope that answers your question.

Indeed, given the needed amount of work put into timing* (for tasks), it would seem VERY odd if the Ada.Calendar package did not deal with leap-year; also, given that it deals with leap-seconds, not dealing w/ leap-year's 29Feb would be inconsistent.

* Granted, for real-time systems the leap-year/leap-second thing is quite undesirable, giving rise to the monotonic time of the Real_Time package.