Newsgroup: it.discussioni.ingegneria
Titolo: ehm... 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

l'offset dal 197?, questo sposta il "problema" al 20?? 
Se non sbaglio, Linux è a posto fino al 2038, ma si ritiene che per
quella data il problema sarà risolto del tutto.
Saluti

    Non ho mai affrontato direttamente il problema, anche se mi ha sempre
incuriosito... Spronato dal tuo post ho cercato qualche documentazione in
merito, trovando però poco. Infatti il problema del calcolo della data a più
basso livello viene risolto dal dos (per i PC IBM Compatibili... da quanto
 non si sente più questa definizione?), e tutti i maggiori libri di
programmazione rimandano alla relativa chiamata all'interrupt 21h.
    E qui sono sorti i miei maggiori dubbi! Il "Programming the 80286,
80386, 80486, and Pentium-based personal computer" di B. B. Brey (la bibbia
dell'assembly), relativamente alla chiamata della funzione 2Ah
dell'interrupt 21h, fornisce i seguenti dati:
Entry: AH = 2Ah
Exit: AL = day of the week
CX = the year (1980-2099)
DH = the month
DL = day of the month
Note: The year is a binary number equal to 1980 through 2099
    Ciò mi ha lasciato perplesso: dove stà allora il problema del cambio di
data 1999-2000 se il dos già da tempo lo gestisce, in apparenza,
correttamente? (Non so la tua conoscenza riguardo le interruzioni della CPU:
se conosci già l'argomento passa avanti! Altrimenti per dirla in breve sono
degli eventi particolari che interrompono il lavoro della CPU
temporaneamente per poter avviare delle routines
particolari. Nel nostro caso leggere la data. Dopo che questa routine è
stata svolta, la CPU torna ad eseguire il flusso di istruzioni in memoria,
ma trova nei suoi registri i dati che erano stati richiesti. Sempre nel
nostro caso, nel registro CX  (16bit) troviamo l'anno).
    Andando però a consultare la guida in linea del vecchio ASMedit ho
capito qualcosa in più:
  INT 21,2B - Set Date _
  ______________________
  AH = 2Bh
  CX = year  (1980-2099)
  DH = month (1-12)
  DL = day   (1-31)
 returns:
  AL = 00h if date change successful
     = FFh if invalid date
  _ sets DOS maintained clock
  _ DOS versions 3.3+ also update the CMOS date where applicable
    Cioè che la data che ottengo (o che imposto) con l'interrupt 21h è una
data "mantenuta" dal dos, e non quella dell'orologio di sistema, che viene
però aggiornata allo stesso tempo. Ma allora come funziona la "CMOS date"?
E' un problema di quest'ultima oppure dei programmi a più alto livello che
non sanno interpretare correttamente l'anno fornito dal dos?
E qui mi fermo anch'io, non sapendo dove cercare qualche informazione in
più.
Spero in qualche altro intervento!
Ciao
--
----------------------------------------------------
Michele Dal Corso
http://space.tin.it/computer/micdalco
Per risposte via email togliere TOGLIMI dall'indirizzo.
----------------------------------------------------
--

 Spero in qualche altro intervento!
Sul numero di "nuova Elettronica" che e` attualmente in edicola,
c'e un articolo che parla in dettaglio della gestione della data
sui PC.
Ciao.
Quirino