Il problema del millenium bug visto dalla parte del calcolo dell’anno bisestile.
[protected]
Secondo Wikipedia
L’anno bisestile è un anno solare in cui avviene la periodica intercalazione di un giorno aggiuntivo nell’anno stesso, un accorgimento utilizzato in quasi tutti i calendari solari (quali quelli giuliano e gregoriano) per evitare lo slittamento delle stagioni: ogni 4 anni accumulerebbero un giorno in più di ritardo. Per correggere questo slittamento, agli anni “normali” di 365 giorni si intercalano anni “bisestili” di 366: il giorno in più viene inserito nel mese di febbraio, che negli anni bisestili conta 29 giorni anziché 28. In questo modo si può ottenere una durata media dell’anno pari a un numero non intero di giorni.
La regola dice che se un anno è divisibile per 4, ma non per 100 è bisestile con un’ eccezione: se l’anno è divisibile per 4 e per 100, ma anche per 400 allora anche in questo caso è bisestile. E’ il caso proprio dell’anno 2000, quello che generò il tanto temuto, ma in qualche modo innoquo millenium bug
[/protected]
Per verificare se un anno è bisestile il codice C-Like potrebbe essere tra gli altri il seguente:
boolean isAnnoBisestile=(anno % 4 == 0 && (anno % 100 != 0 || anno % 400 == 0));
La curiosità mi ha spinto oltre per verificare quali software che in qualche modo usiamo ogni giorno possono aver sofferto del bug di non considerare l’eccezione della divisibilità per 400.
E attenzione attenzione… se consideriamo gli anni 1900 e 2000 entrambi divisibili per 4 e per 100 risulta che il primo non è divisibile per 400, mentre il secondo si.
Per cui in base alla regola il 1900 non è anno bisestile, mentre il 2000 si.
Guardate questo video in cui scrivo 29/2/1900 in Excel ed in Open Office Calc.
(METTERE A TUTTO SCHERMO, qualità pessima, mettete in pausa alla fine per guardare bene le differenze)
Notate la differenza?
