Buongiorno,
l’altro giorno stavo cercando di accedere tramite eIDAS in un sito web del governo lituano, durante il login, attraverso CIE, il mio account segnalava che la data di nascita errata di un giorno, per correttezza ho provato ad accedere anche con lo SPID e l’errore è ancora presente.
Ho fatto notare ciò all’assistenza lituana che dopo aver effettuato alcune verifiche non ha trovato problemi nella ricezione dei dati da parte loro. Ho dunque segnalato la cosa via email a servicedeskeidas@agid.gov.it ma non ho ricevuto risposta.
Ho anche controllato su un sito italiano attraverso il login con CIE/SPID e la data di nascita risulta corretta. Ho anche controllato il profilo su PosteID e la data risulta corretta.
C’è dunque un errore sul nodo italiano di eIDAS che invia una data di nascita errata di un giorno? Qualcuno può verificare?
In Lituania sono difatti un ora avanti all’Italia.
C’è un modo per risolvere localmente, es. cambiando orario del PC mettendolo uguale al paese del servizio, oppure è necessaria una modifica da parte dei server di eIDAS?
Esatto, questo è un problema annoso e dovuto a un problema concettuale nello sviluppo.
Chi lavora con i sistemi informatici dovrebbe distinguere molto attentamente il concetto stesso di data intesa come giorno di calendario e data-ora-fuso, inteso come insieme della data, ora e fuso orario di riferimento.
Quanto descritto accade perché c’è l’odioso vizio, ma altrettanto l’odiosa limitazione da parte delle librerie, di rappresentare una data del calendario come il suo equivalente della mezzanotte data-ora (es. “1991-01-10 00:00:00” a indicare tutta la giornata), con l’evidente risultato che spostando il device di fuso orario se quell’informazione diventa le 23 del giorno prima, essa viene troncata al giorno prima di calendario.
Negli USA, dove l’informatica nasce e cresce più di ovunque, questo problema non l’hanno mai avuto avendo offset tutti negativi.
In poche parole, è indispensabile che le figure coinvolte nello sviluppo (dall’analista allo sviluppatore) rappresentino il dato per come esso è, senza ricorrere ad oggetti di tipo “new Date”, “ISODateTime”, ecc., altrimenti si incorre il serio rischio che in documenti ufficiali vengano riportate date inesatte, non sempre rilevabili in fase di test.
Riassumendo: il consiglio che do agli sviluppatori è usare le stringhe in formato “yyyy-MM-dd”, le colonne relazionali di tipo “DATE” (e non “TIMESTAMP”) quando si parla di date di nascita, date contabili, ecc. ecc. per evitare pastrocchi.
Ovviamente tutto quello che dici e’ corretto, ma sono convinto che sia una interpretazione vecchia. Con l’informatica ed Internet sarebbe necessario ridefinire il concetto di data in modo univoco.
Se un bambino nasce in un fuso orario diverso da quello di cui avesse la nazionalita’, se chiedessi il codice fiscale (o il suo equivalente, o un qualunque documento) il giorno stesso della nascita (quando magari nel paese che lo rilascia e’ ancora il giorno precedente) cosa succederebbe ? Caso estremo, ma molto plausibile ora che questa operazione (con l’informatizzazione della PP.AA. ) puo’, magari, essere svolta dal cellulare in un paio di click.