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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8c564a80b820db35 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.189.197 with SMTP id gk5mr12961193pbc.1.1330963171504; Mon, 05 Mar 2012 07:59:31 -0800 (PST) Path: h9ni42526pbe.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Any leap year issues caused by Ada yesterday? Date: Mon, 5 Mar 2012 07:59:30 -0800 (PST) Organization: http://groups.google.com Message-ID: <20608866.730.1330963171058.JavaMail.geo-discussion-forums@ynbq18> References: <4f4f746a$0$6565$9b4e6d93@newsspool3.arcor-online.net> NNTP-Posting-Host: 24.230.151.194 Mime-Version: 1.0 X-Trace: posting.google.com 1330963171 10909 127.0.0.1 (5 Mar 2012 15:59:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 5 Mar 2012 15:59:31 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=24.230.151.194; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-03-05T07:59:30-08:00 List-Id: On Monday, March 5, 2012 5:07:29 AM UTC-6, tonyg wrote: > On Mar 1, 1:06=A0pm, Georg Bauhaus > wrote: > > News travels the wires of the internet telling us about MS Azure outage= s > > in several places. These were seemingly caused by a piece of software > > handling calendar dates involving February 29, 2012. > > > > =A0Which 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. =A0The issue was quickly triaged and it was determined to be c= aused by > > a software bug. =A0While 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. =A0The fix was successfully deployed to most of the Wind= ows > > 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..= . >=20 > 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 wo= uld 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 29F= eb would be inconsistent. * Granted, for real-time systems the leap-year/leap-second thing is quite u= ndesirable, giving rise to the monotonic time of the Real_Time package.