Dopo aver analizzato la gestione dell'escaping e dell'encoding vediamo la gestione delle date.
Se la nostra webapp è raggiungibile da Internet significa che può essere utilizzata da luoghi con fusi orari differenti da quello in cui risiede il nostro server. Inoltre il server può risiedere fisicamente in un paese con il fuso orario o timezone diverso dal nostro.
Per poter gestire correttamente questo scenario bisogna fare delle scelte consapevoli a livello di applicazione.
Una scelta potrebbe essere quella di impostare come timezone dell'applicazione e del database l'UTC: questo ci dà un punto di riferimento fisso nel tempo per la nostra webapp indipendentemente da dove si trova il server ospitante (hosting). In più, grazie a questa scelta, se sviluppiamo in PHP non dovremo preoccuparci della differenza tra date e gmdate poiché sarà del tutto indifferente.
In PHP per utilizzare questo timezone dovremo utilizzare la funzione date_default_timezone_set come nel modo seguente:
date_default_timezone_set('UTC');Per quanto riguarda invece il database MySQL subito dopo la connessione si potrà eseguire lo statement SQL:
SET time_zone = '+00:00';A questo punto non resta che ragionare sui casi che si possono presentare quando un utente indica una data/ora e come gestirli rispetto alla scrittura su DB, alla successiva lettura e alla presentazione lato utente.
I casi possibili da gestire sono 2:
- Caso 1: l'utente esprime una data/ora in modo assoluto o comunque non rispetto al proprio timezone es. "Arriverò da voi il 10 agosto 2012 alle 8:40";
- Caso 2: l'utente esprime una data/ora rispetto al proprio fuso orario es. "Passate a ritirare il pacco il 3 settembre alle 9:10";
Scrittura su DB:
- Caso 1: la data va salvata così com'è su database (e quindi la si considera espressa rispetto al timezone del server, cioè UTC);
- Caso 2: la data va convertita dal timezone dell'utente al timezone del server (UTC) in fase di salvataggio.
Lettura da DB e presentazione:
- Caso 1: la data va letta e inviata all'utente così com'è, senza conversioni;
- Caso 2: la data va letta e convertita nel timezone dell'utente prima di inviargliela.
In ogni caso, internamente, la logica del programma ragionerà su date e ore in UTC, l'eventuale conversione da e verso il timezone dell'utente avverrà subito dopo aver ricevuto il dato in input e subito prima di inviare il dato in output.