Date e fusi orari sono cose complicate e, in generale, a prescindere dal tipo di stack tecnologico su cui si sta lavorando, raramente una soluzione chiavi in mano.
La maggior parte dei database memorizzerà una data o un timestamp come poco più della data esatta o timestamp che gli è stata data. Quando si parla con un database tramite query, generalmente si presuppone che tutte le date e gli indicatori di data e ora rappresentino un punto temporale in uno stesso fuso orario. In altre parole, se scrivo una query per vedere se il 2 agosto 2012 16:10 sia precedente alla stessa data alle 17:10, allora valuterò la verità restituendomi quel record. Supponiamo che il record sia stato salvato come 4:10 pm Eastern Standard Time quando il mio server di database si trova in Pacific Standard Time. Il database è agnostico del fuso orario e ora la mia query non restituisce i dati che mi aspetto.
Converti tutte le date e le ore delle applicazioni in UTC o GMT prima di persistere
Lingue come Java, Javascript e C # trattano date e orari in modo leggermente diverso. In genere misurano il tempo come un numero di millisecondi da un dato punto universale nel tempo. Questo è il tempo universale in quanto quel numero specifico di millisecondi da 0 rappresenta un numero di date o orari diversi in fusi orari diversi in un dato punto. La maggior parte di queste lingue ha in genere un'API data e ora solida o una buona libreria di terze parti che consente di visualizzare il millesimo di secondo in un numero di fasce orarie il più indolore possibile.
Se non diversamente specificato, se utilizzo un'API di accesso ai dati standard in un linguaggio comune, la maggior parte prenderà un oggetto data e lo convertirà nella data e ora del fuso orario predefinito del server nel formato di database specificato. Scopri come i tuoi dati di lingua accedono alle API e alle date di memorizzazione dei database e come li interpreta dal database e prova a memorizzare le date a livello di database in GMT. Allo stesso modo, quando esegui una query, assicurati che gli oggetti Date o le variabili nella tua lingua rappresentino un conteggio millisecondo equivalente all'ora di data GMT memorizzata nel database.
Fusi orari per le date utilizzate in Business Logic
Ciò che intendo è che forse se hai una colonna Data modificata nel tuo database, allora potrebbe non essere importante per la logica di business, tuttavia una Data appuntamenti di colonna probabilmente sarà importante.
Da qualche parte nello schema è necessario determinare dove sono archiviati dati specifici della locale e memorizzare il fuso orario per definire quella locale nella tabella genitore appropriata. La logica aziendale che prende in considerazione le date o la logica di presentazione che sta preparando le date per la visualizzazione deve essere in grado di recuperare il fuso orario appropriato in modo che quando paragono dalle 16:10 alle 17:10, sto confrontando le date dall'apposito spazio universale tempo. 16:10 EST e 16:10 PST sono punti separati nel tempo universale. Anche in questo caso una buona API di data e ora o una libreria di terze parti facilita il confronto delle date, quando capisci la natura sottostante di come funzionano le date in quel linguaggio di programmazione.
Business Logic dovrebbe essere sottoposto a refactoring in modo da essere al corrente del fuso orario.
Logica di presentazione dovrebbe essere refactored per presentare un valore di visualizzazione che visualizza in modo appropriato i dati corretti per il fuso orario appropriato appropriato.
Un ultimo pensiero da considerare quando si esegue questo lavoro è scrivere esaurienti test unitari che esauriscano completamente molti tipi di combinazioni di data e ora per assicurarsi che tutta la logica aziendale funzioni come previsto.