Timezones e altre brutte bestie

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.

 

The best way to handle time zones in a Java web application

This entry was posted in Italian Content and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.