Problema anno 2038 con libreria time.h

[ivanpascolo]

Salve,
sto lavorando ad un progetto con RTC e dovendo fare dei calcoli con le date mi sono imbattuto nella libreria standard time.h (sto utilizzando un pic1846k22). Il mio problema è che la funzione mktime che ha il compito di restituire i secondi a partire dal 1 gennaio 1970, ha il limite che non va oltre il 2038. Mi metterei volentieri a realizzare una libreria che fa al caso mio ma non ho grande esperienza con il C e non sono ancora in grado di fare grandi cose. Se qualcuno può darmi una mano .... grazie.

[eAlucarD]

martedì 19 gennaio per la precisione il problema riguarda tutti i sistemi con time_t di soli 32bit
in quelli a 64bit il problema si ripresenta tra 290 miliardi di anni

perché rappresenta un problema ? (per il tuo progetto intendo)

puoi sempre fare i "conti" spezzando le date

[ivanpascolo]

Volevo fare tutto con un'unica libreria ma se mi viene difficile dovrò fare come mi suggerisci tu.

[angel99]

Quando leggo queste cose me ne convinco sempre più:

assembler for life.

[TardoFreak]

Il problema non è il linguaggio. Ad un certo livello un linguaggio vale l' altro.
Con tutto il rispetto, il problema è che lui non sa come fare, indipendentemente dal linguaggio.

[angel99]

Era un piccolo OT, ma poi forse anche no. Nel senso che più che parlare di differenza tra un linguaggio e un altro, sarebbe da valutare la differenza tra librerie proprietarie e quelle standard che trovi con i compilatori.
Se scrivo la mia lib (che sia in asm, C, o... RPG) conosco i limiti di ciò che ho fatto, o almeno dovrei. Se invece prendo una libreria standard... chi lo sa?

[GuidoB]

Se scrivo la mia lib (che sia in asm, C, o... RPG) conosco i limiti di ciò che ho fatto, o almeno dovrei. Se invece prendo una libreria standard... chi lo sa?

In teoria dovrebbe essere documentato ciò che la libreria fa e quali sono i suoi limiti.
Poi, non è sempre così.

Certo che scriversi tutte le librerie per conoscerne i limiti è un lavoro immane, e non resta tempo per fare altro (ovvio che dipende da quante librerie ti servono).
E poi le devi debuggare

Una soluzione è andarsi a vedere i sorgenti della libreria i cui limiti non sono documentati. Leggendo attentamente il codice sorgente dovrebbero esserne chiari i limiti.

E se il sorgente non è disponibile?
Io ho trovato utile leggere i sorgenti di altre librerie open source. Non c'è nessuna garanzia, ma a me è sempre andata bene. I limiti erano gli stessi delle librerie closed source.

In particolare posso suggerire la libreria di Sanos, un sistema operativo minimalista open source. Qui (link "Download" dopo il testo) si può scaricare un maneggevole file zip coi sorgenti (colonna "Download source"). Dentro lo zip, in src/lib, ci sono le librerie per il C, compreso time.c; in src/include/sys/types.h ci sono le definizioni di tipo (compreso time_t). Da qui ivanpascolo può ispirarsi per scrivere la sua libreria... buon lavoro!

Ho letto da qualche parte che, se non si può usare un tipo a 64 bit per time_t, invece di dichiararlo long (32 bit con segno) si può dichiararlo unsigned long (32 bit senza segno). Non si potranno più trattare date precedenti al 1970, ma il problema dell'anno 2038 viene spostato molto più avanti (al 2106 se non erro).

Ho visto che qui qualcuno si è già posto il problema e qui propone almeno un pezzo di libreria con la (sua) soluzione implementata.

[angel99]

E' una scelta.

Ovviamente nessuno si può scrivere Office per essere sicuro di avere un software infallibile per compilare una fattura, ma per ciò che riguarda i micro, sono oltre dieci anni che ho scelto la strada del fai da te.

Il vantaggio che mi ha convinto sia stata una strada vincente è stato al momento del porting da una famiglia ad un'altra. In questo periodo sto facendo il porting dal TI all'AVR ed è un lavoro tranquillissimo, che richiede pochissimo impegno (a dispetto della struttura molto differente delle due famiglie). Mi chiedo cosa sarebbe stato compilare un programma in C e trovare che metà delle funzioni hanno paradigmi diversi, diversi limiti di validità e chissà che altro.

Certo, ti puoi leggere tutto il codice fatto da qualcun altro, ma ci impieghi il triplo che a leggere il tuo e di sicuro non trovi tutto quello che dovresti trovare.

[TardoFreak]

Scusa la domanda, sono solo curioso: usi ancora micro ad 8 bit?
E se si, perché?

[angel99]

La maggior parte del lavoro è con gli 8 bit.

Lavoro come consulente per un'azienda che fa produzione di serie e quando devi progettare un terminale con tastiera, display, interfaccia seriale, link infrarosso, RTC con batteria, quattro condizionatori 4-20 mA in ingresso e quattro relè di uscita che deve costare 4 Euro e mezzo, non c'è posto per i 32 bit o per i 64 k di flash.

La famiglia TI che abbiamo adoperato per anni è a 16 bit, ma abbiamo dovuto tornare agli 8 bit per questioni economiche. E' un lavoro molto più complesso, ma è l'unico modo per poter competere a livello internazionale.