Sto costruendo un'applicazione con eventi in diversi paesi e città. Un evento viene sempre presentato nell'ora locale di un luogo in cui si verifica. Quindi penso che non avrò bisogno di informazioni sul fuso orario insieme a una data-ora di un evento nel database.
Ci sono argomenti contro questo? Devo cambiare idea e memorizzare un fuso orario o GMT + N di un evento incorporato nel suo "start_date_time"?
tl; dr
Altri dettagli
Secondo la mia esperienza, il modello più raccomandato e utilizzato è quello di memorizzare date e ore nel fuso orario di Etc / UTC ( Fusi orari IANA ) e per visualizzare le date e le ore nell'ora locale dell'utente che visualizza le informazioni. Ciò rende le date e le ore facilmente confrontabili e ordinabili sul lato server e facilmente convertibili in ora locale per la visualizzazione.
Se il tuo requisito è solo quello di visualizzare le ore e le date locali in un browser o un'applicazione nativa in base alla posizione dell'utente, non è necessario memorizzare il fuso orario per ogni volta. I buoni strumenti dell'interfaccia utente, inclusi i browser, possono convertire i tempi UTC e le epoche (che sono per definizione UTC) in base all'ora locale.
Se hai altri requisiti potresti aver bisogno di memorizzare il fuso orario. È necessario anche memorizzare il fuso orario se ... ad esempio ...
Si desidera visualizzare le date e le ore di un evento nell'ora locale in cui si verifica l'evento, indipendentemente da dove si trovi attualmente l'utente che visualizza le informazioni. (Credo che questo fosse il tuo requisito.) Il fuso orario dovrebbe probabilmente essere un attributo dell'evento.
Hai sempre bisogno di produrre l'output nell'ora locale di un utente o di un evento dai tuoi server. Esempi: pdf, contenuto di posta elettronica, carta prodotta in base alla pianificazione e non direttamente in risposta alla richiesta di un utente. In questo caso, il fuso orario potrebbe essere una preferenza utente o un attributo evento.
Se vuoi memorizzare il fuso orario, dovresti generalmente utilizzare i fusi orari IANA come Etc / UTC e America / Los_Angeles. Sono il più ampiamente supportato da strumenti di sviluppo, librerie temporali, ecc. Sono convertibili in fusi orari Windows ( vedi questa domanda )
Non abbastanza dettagli? - Perché gli offset sono diversi dai fusi orari?
La memorizzazione di un offset UTC come -08: 00 non equivale alla memorizzazione di un fuso orario. Un offset UTC è valido per archiviare, recuperare e visualizzare un orario specifico, ad esempio 2017-09-09T12: 00: 00-08: 00. Ti consente di visualizzare quell'ora locale in qualsiasi momento nel futuro e di convertirla in UTC.
A seconda degli strumenti utilizzati, la memorizzazione di uno scarto potrebbe non soddisfare le tue esigenze. Ad esempio:
Le tue esigenze potrebbero dettare la necessità di conoscere il fuso orario di un evento rispetto all'offset di qualsiasi momento associato all'evento. Ciò ti consente molta più flessibilità in ciò che puoi fare dopo. È sempre possibile ricreare offset da un fuso orario utilizzando una buona libreria del tempo. Non puoi sempre dedurre in modo affidabile il fuso orario da un offset.
Dovresti implementare tutto questo da solo? No. Ci sono molti buoni strumenti per aiutarti. Assicurati di leggere i limiti dei tipi di orario del database e altri strumenti prima di utilizzarli. Ci sono stati un sorprendente numero di problemi con il supporto di linguaggio e dbms per il tempo, e fortunatamente un bel po 'di librerie di data / ora che riprendono il gioco.
Se memorizzi le ore locali, potresti avere un problema con il tempo di salvataggio diurno o qualsiasi altra modifica del fuso orario.
Per ottenere ciò, un'ora viene "portata via" o "aggiunta". Il primo caso potrebbe farti pensare che due eventi accaduti a un'ora di distanza l'uno dall'altro siano avvenuti a 2 ore di distanza. Nel secondo caso, gli eventi che si sono verificati in due ore diverse saranno misti su quello che è accaduto per primo (o un evento che può accadere solo una volta all'ora non sarà permesso che accada in un'ora diversa, poiché entrambi sembrano essere gli stessi).
Una soluzione semplice sarebbe quella di memorizzare tutte le date su UTC 0 e regolarle per adattarle al luogo di appartenenza. In questo modo, avrai sempre un certo punto nel tempo, quindi nessun dato perso e dovrai regolarlo nel posto corrispondente.
Se si memorizza solo l'ora locale, non è possibile utilizzarlo per i calcoli.
Ad esempio. Diciamo che sto prendendo un volo da Londra a Parigi. Londra è a 1 ora di ritardo da Parigi, il mio volo parte alle 10 e arriva alle 13:00. Quanto dura il volo?
Oppure, dire che voglio svegliarmi presto per assistere alla grande battaglia, che si terrà a Las Vegas alle 23:00 (PT), ma la guarderò in diretta TV a New York. Si scontrerà con il mio spettacolo preferito alle 21:00 (EST)
Anche la memorizzazione della correzione UTC, ovvero ISO 8601, è anch'essa difettosa. L'ora legale cambia l'offset UTC di un tempo, quindi 2300 + 0100 più 2 ore potrebbero non essere 0100 + 0100 (o meglio lo sarà, ma il 0100 bit non è più l'ora locale)
Di solito è consigliabile archiviare tutti i tempi in UTC e convertirli all'ora locale richiesta quando li si visualizza. Che richiede il fuso orario.
Gestire correttamente date, orari, calendari, fusi orari, ecc. è qualcosa che sembra semplice ma notoriamente difficile per avere ragione. Quindi, per prima cosa, è chiedere a te stesso: è questo:
Questo deve essere corretto al 100%, oppure deve essere per lo più corretto, ma di tanto in tanto riesco a gestire alcuni errori occasionali?
Bene, indipendentemente da quale sia la risposta, non credo che l'OP abbia una scelta e debba andare con quest'ultima, perché uno dei commenti di OPS:
If you store local times, you could have a problem with daytime saving time or any other timezone change. -- I don't understand
Mi dice che il PO è seriamente mal preparato per farlo correttamente.
Quindi, per rispondere alla tua domanda, devi assolutamente tenere traccia dei fusi orari. Non ho nemmeno letto le specifiche concrete della domanda, perché so che quando si tratta di date e orari, se si vuole fare bene, bisogna andare fino in fondo. Ma prima di iniziare qualsiasi programmazione, fai qualche ricerca sulle difficoltà di una corretta gestione della data-ora.
Leggi altre domande sui tag database database-design