Newsgroup: it.scienza.informatica
Titolo: aehm.... millenium bug

So bene che negli ultimi tempi riviste, quotidiani e telegiornali hanno
sparato a zero sul problema, spesso e volentieri con affermazioni da circo,
ma... anch'io ho i miei dubbi (leggermente + tecnici).
Queste le premesse che si leggono ovunque:
nei tempi che furono le memorie dei calcolatori erano "immensamente costose"
per questo i computer non ne montavano tanta ed i programmatori facevano di
tutto per elemosinare qualche byte, così senza molto curarsi di ciò che
sarebbe potuto accadere in futuro implementarono la rappresentazione della
data in numerosissimi programmi utilizzando solo 2 cifre decimali, da qui il
problema che il passaggio 99 --> 00 potrebbe essere visto da molti
calcolatori come un ritorno nel passato
(a proposito, è successo effetivamente qualcosa?).
Questo il mio problema:
volendo rappresentare il numero 99 come unsigned int ho bisogno di almeno 7
bit i quali mi forniscono un range di rappresentabilità [0,127] --> dove sta
il problema?
A meno di non utilizzare altri tipi di rappresentazione (che commento tra un
attimo) il numero massimo rappresentabile sarà sempre una potenza di 2 meno
un'unità (quindi nessun 10, 100 o 1000 possono far accendere il mio OF).
Mi sono detto: per riscontrare il problema dobbiamo utilizzare una
numerazione modulo 10 --> che le date vengano rappresentate in BCD (binary
coded decimal)? Se così fosse, però, anche utilizzando una codifica packed
BCD, avrei bisogno di utilizzare 8 bit per rappresentare il range [0,99], un
bit in più per un range inferiore.
E' ovvio a questo punto che la base del mio problema sta nel non sapere come
EFFETTIVAMENTE un calcolatore gestisca le date: so per certo che nei SO
Unix-like la data viene calcolata utilizzando un numero che rappresenta
l'offset dal 197?, questo sposta il "problema" al 20?? anche se il kernel di
Linux, per esempio, dovrebbe già essere immune a questo BACO (che traduzione
da schifo! ma perchè si deve sempre italianizzare tutto?): anche in questo
caso come è visualizzata poi la data ? anche se la CPU conta un offset ciò
che deve far apparire sullo schermo è sempre un numero "completo", che
gestisca il tutto come una stringa?
mha, aiutate questa persona confusa. Mi scuso per la lunghezza del msg e per
la futilità dell'argomento.
Buon Anno a tutti!
n!c0

 wrote:
: Questo il mio problema:
: volendo rappresentare il numero 99 come unsigned int ho bisogno di almeno 7
: bit i quali mi forniscono un range di rappresentabilità [0,127] --> dove sta
: il problema?
Il problema non e` nella rappresentazione ma nell'uso che se ne fa.
esempio 1: io scrivo le date come aammgg, in modo che decido se data1 e`
successiva a data2 facendo un test data1>data2 . Fallo con 991231 e 000101.
esempio 2: io uso solo due byte per l'anno. La mia applicazione perl (che
ritorna "anno-1900") adesso ha come anno "100", ma io lo salvo come 00.
Quando rileggo la data, mi viene 1900.
.mau.

Salve
cito
"esempio 2: io uso solo due byte per l'anno. La mia applicazione perl (che
ritorna "anno-1900") adesso ha come anno "100", ma io lo salvo come 00.
Quando rileggo la data, mi viene 1900."
gia', e perche' non 1800 o 2100? 
Cheers
Yuri

 questo sposta il "problema" al 20??
no al 2038, ma per un'altra ragione, *nix indica data e ora come i
millisecondi trascorsi dal 1/1/1970 solo che sulle macchine a 32 bit
questa variabile andra' in overflow nel 2038.

gestisca il tutto come una stringa?
Due note. Primo, la stragrande maggioranza delle istituzioni a rischio (banche, 
istituti finanziari) non usa sistemi operativi moderni (come uno Unix), quanto 
s/o per mainframe o sistemi proprietari. E la convenzione di usare un long col 
numero di millisecondi dall'1/1/70 non e' propria di molti di questi sistemi 
operativi.
Secondo, questo e' del resto poco rilevante. In quasi tutte le applicazioni, 
cio' che "gestisce" le date non e' il sistema operativo, ma l'applicazione 
stessa. Il servizio di s/o per la data e' - quasi sempre e unix compreso - 
quello di "istante corrente". Tutti gli altri calcoli (confronti, cambi di 
scala, calcoli di calendario, eccetera) sono a carico dell'applicazione - che 
quindi usa librerie o logica interna. Ecco quindi il problema.
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/

Pape' Satan, pape' Satan aleppe, comincio' nIcO con voce chioccia:
n> Mi sono detto: per riscontrare il problema dobbiamo utilizzare una
n> numerazione modulo 10 --> che le date vengano rappresentate in BCD (binary
n> coded decimal)? Se così fosse, però, anche utilizzando una codifica packed
in effetti se non sbaglio nel CMOS dei nostri computer la data e'
memorizzata in BCD. Anche se, come faceva notare .mau., il problema
sta piu' nell'uso che se ne fa della data...
n> Unix-like la data viene calcolata utilizzando un numero che rappresenta
n> l'offset dal 197?, questo sposta il "problema" al 20?? anche se il kernel di
n> Linux, per esempio, dovrebbe già essere immune a questo BACO (che traduzione
non credo. Linux, come gli altri unix, avra' qualche problema nel
2038, quando una variabile a 32 bit non riuscira' piu' a contenere i
secondi passati dal 1 gennaio 1970.
Anzi, andando a spulciare nei sorgenti del kernel di linux troviamo
questo (in arch/i386/kernel/time.c):
 * WARNING: this function will overflow on 2106-02-07 06:28:16 on
 * machines were long is 32-bit! (However, as time_t is signed, we
 * will already get problems at other places on 2038-01-19 03:14:08)
 */
-- 
ciao,
Claudio

Pape' Satan, pape' Satan aleppe, comincio' Maurizio con voce chioccia:
MC> esempio 2: io uso solo due byte per l'anno. La mia applicazione perl (che
MC> ritorna "anno-1900") adesso ha come anno "100", ma io lo salvo come 00.
MC> Quando rileggo la data, mi viene 1900.
molti programmatori perl invece si sono ritrovati proiettati 
direttamente in un remoto 19100 :-) Auguro davvero al perl di durare
cosi' a lungo, visto che e' un gran bel linguaggio.
-- 
ciao,
Claudio

Salve cari espertoni
ho letto le vostre mail e mi paiono piene di buoni e ragionevli argomenti,
mi spiegate allora come fa un PC con Windows 3.1 e MS_DOS 6.22 che i 
programmi di test mi davano per certo che sarebbe defunto il 1 Gennaio
2000 a funzionare correttamente (l'ho bootstrappato il 4/1) e a segnare 
correttamente la data?
Chers
Yuri
PS Dalle mail di Claudio e Maurizio mi pare che si evinca solo che il problema
sta nel tenere fisse le prime due cifre dell'anno dato che Claudio dice 
se salvo come 00 allora mi viene 1900 
ergo il problema sta nel concatenare due stringhe, una fissa a 19 e una
ricavata dall'algoritmo...
Per i contatori sotto *nix non credo che nessuna delle macchine attuali veda
il 2038 e nemmeno nessuna delle versioni attuali dei vari *nix per cui non
mi preoccuperei piu' di tanto. In piu' mi pare con un conto a spannometro
che 2^32 sec siano 136 anni e che 136 anni dal 1970 sballino il 2100....
Ri-cheers
Yuri

 wrote:
: Per i contatori sotto *nix non credo che nessuna delle macchine attuali veda
: il 2038 e nemmeno nessuna delle versioni attuali dei vari *nix per cui non
: mi preoccuperei piu' di tanto. In piu' mi pare con un conto a spannometro
: che 2^32 sec siano 136 anni e che 136 anni dal 1970 sballino il 2100....
Si, ma il contatore e` un signed long.
.mau.

Salve
il fatto che sia un long non inficia la prima parte dell'argomento e 
comunque mi pare che l'overflow di tale long non abbia nessuna 
correlazione con il bug dato che comunque un contatore a dimensione
finita va in overflow e il quando dipende dal momento in cui viene
iniziato il conteggio e la velocita' del conteggio per cui mi pare
che la discussione sia bene riportarla "nel seminato" e al proposito
nessuno (e nemmeno te) ha saputo dirmi il perche' anche l'hardware piu'
vecchio (ho dei MacSE con il 6.1) abbia superato indenne la terribile prova
del pasaggio di millennio e cio' nonostante che programmi di test da me
usati mi dicessero che tale hardware mai e poi mai sarebbe sopravvissuto
al micidiale baco... Nel caso del PC da me citato ho usato un programma
che me lo dava spacciato gia' a livello del BIOS...
Cheers
Yuri

 wrote:
: Salve
: il fatto che sia un long non inficia la prima parte dell'argomento
Infatti non ci sono problemi sino al 2038 per le macchine unix.
: nessuno (e nemmeno te) ha saputo dirmi il perche' anche l'hardware piu'
: vecchio (ho dei MacSE con il 6.1) abbia superato indenne la terribile prova
: del pasaggio di millennio
Perche` *l'hardware* (e il bios, per essere pignoli) non aveva nessun
problema. Persino msdos 1.0 (1980) era fatto per avere la data a posto fino
al 2099. Ripeto che i problemi stavano nelle applicazioni, soprattutto
quelle scritte in COBOL (che usava un carattere per cifra).
Tra l'altro, sarebbe stato molto piu` preoccupante se il 2000 NON fosse
stato bisestile, almeno a mio parere. 
: e cio' nonostante che programmi di test da me
: usati mi dicessero che tale hardware mai e poi mai sarebbe sopravvissuto
: al micidiale baco... 
Fai partire un po' di neuroni e rispondi a questa simpatica domanda:
chi ti ha "regalato" i programmi di test da te usati?
ciao, .mau.

il fatto che sia un long non inficia la prima parte dell'argomento e 
Maurizio diceva un *signed* long, in cui il primo bit e' il segno. Quindi, 
assumendo un long a 32 bit e la codifica standard per gli interi, hai spazio 
per 2^31+1 interi positivi o nulli cioe' 
2147483648
+1 (e non 2^32).
Che, considerando 864*10^2 secondi al giorno, bastano fino al 2038. 


Salve 
cito
"Maurizio diceva un *signed* long, in cui il primo bit e' il segno. Quindi, 
assumendo un long a 32 bit e la codifica standard per gli interi, hai spazio 
per 2^31+1 interi positivi o nulli cioe' 
2147483648
+1 (e non 2^32).
Che, considerando 864*10^2 secondi al giorno, bastano fino al 2038"
sono stupe-fatto dalla tua cultura, dimmi o vate sei allora certo che Linux Red 
Hat sara' ancora in giro nel 2038 in modo che ci sia dato il sommo gusto di  
vedere il suddetto contatore andare in overflow? Questo e' il succo del mio
argomento..
Comunque mio caro saputello su n bit codifichi in unsigned da 0 a 2^n -1 e 
e cioe' 2^n valori e non 2^n + 1 come pensi tu e che bel pensiero dire che
possono essere o positivi o nulli.. in queale aritmetica senza segno esistono
piu' codifiche per lo 0? Senza contare che se il tipo e' signed long  puo'
contenere rappresentazioni da -2^(n-1) a 2^(n-1) -1 per cui almeno in teoria
2^n valori . Su come usare i valori con il msb a 1 per il conteggio del
tempo la caccia e' aperta ma comunque tornando a bomba mi pare che tutto cio'
non c'entri un emerito nulla con il problema dell'oggetto di questo thread..
Cheers
Yuri

millisecondi trascorsi dal 1/1/1970 solo che sulle macchine a 32 bit
 ^^^^^^^^^^^^
Secondi, non millisecondi.
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(per rispondere via email fai un rot13 dell'indirizzo)
(apply a rot13 to reply)




thread.. 
L'oggetto del thread e' "millenium bug". Il millenium bug ha a che fare
con la rappresentazione delle date. Un signed long e' usato per
rappresentare la data in sistemi unix. La connessione e' evidente. 




 sta piu' nell'uso che se ne fa della data...
Infatti. Se nel Bios c'č qualche istruzione del tipo:
if (data non gestita){
    formatta tutto il formattabile
    bloccati
}
allora poco si puň fare.
Credo perň che di BIOS scritti cosě ce ne siano pochi...
--
Alessandro Monti

 fCpb4.6028$Oo1....@news.infostrada.it...
<<snip>>
Mi sembra di capire che il BIOS non "accetta" date
le cui due cifre finali siano minori di 96,
resettando il CMOS a ogni reboot.
Invece le due cifre del secolo "20" evidentemente
non sono gestite e restano come impostato.
Soluzione noiosa ma funzionante per DOS e Win95:
nell'autoexec.bat metti il comando "date" cosě
il PC all'avvio si ferma chiedendoti di impostare
la data corretta.
Ciao, ViDM