Le applicazione odierne girano su 24×7 e spesso su più fusi orari contemporaneamente, e magari hanno clienti distribuiti su più fusi.
Questo può portare a problemi nella gestione delle date non indifferenti.
Storicamente le prime versioni dei database e dei linguaggi di programmazione non gestivano il fuso orario (timezone).
Per es in Oracle l’oggetto DATE memorizza sia la data che l’ora, ma l’ora è senza l’indicazione del fuso. Idem in Java l’oggetto ‘Date’ non registra l’indicazione del fuso.
In entrambi questi casi il fuso orario è quello “di default” del database o di Java.
Se però usate un applicazione moderna scritta in Angular, anche tale applicazione gita su un fuso, che è quello della macchina su cui gira…il browser dell’utente.
E’ ovvio che se il browser e il server girano nel medesimo fuso il problema non si pone ma…come immaginate non è detto.
Se ognuna di questi oggetti mantenesse l’indicazione del fuso orario, sarebbe tutto più semplice: la mezzanotte di Greenwich sono l’una a Roma, ma il momento è il medesimo.
Se invece una data non ha l’indicazione del fuso, le due date non sono confrontabili (è come se fossero due entità diverse).
La soluzione più semplice è tenere tutti i server allineati all’UTC (=ora di Greenwitch) e ottenere dal lato client il fuso a cui lavora, in modo da fare gli adattamenti se necessari.
Difatti se il lato client mi invia una data, devo sapere da che fuso proviene per poterla correttamente gestire.
NB: al giorno d’oggi i software sopra descritti hanno data type che gestiscono il fuso.