Innanzitutto, riconosci che nella terminologia moderna dovresti dire UTC anziché GMT. Sono per lo più equivalenti, tranne per il fatto che UTC è definito in modo più preciso. Riserva il termine GMT per fare riferimento alla parte del fuso orario nel Regno Unito in vigore durante i mesi invernali con offset UTC+0.
Ora alla tua domanda. UTC non è necessariamente il modo migliore per memorizzare tutti i valori di data e ora. Funziona particolarmente bene per il passato eventi, o per futuri assoluti eventi, ma non funziona molto bene per il futuro locale eventi, in particolare ricorrenti futuri eventi.
Ho scritto di questo su un'altra risposta recentemente ed è uno dei pochi casi eccezionali in cui l'ora locale ha più senso dell'ora UTC. L'argomento principale è il "problema della sveglia". Se imposti la sveglia in base all'ora UTC, ti sveglierai un'ora prima o in ritardo il giorno delle transizioni dell'ora legale. Questo è il motivo per cui la maggior parte delle persone imposta la sveglia in base all'ora locale.
Ovviamente non puoi solo memorizza un'ora locale se stai lavorando con dati provenienti da tutto il mondo. Dovresti memorizzare alcune cose diverse:
- L'ora locale dell'evento ricorrente, ad esempio "08:00"
- Il fuso orario in cui è espressa l'ora locale, ad esempio "America/New_York"
- Il modello di ricorrenza, in qualsiasi formato abbia senso per la tua domanda, ad esempio giornaliero, bisettimanale o il terzo giovedì del mese, ecc.
- Il prossimo immediato Data e ora UTC equivalenti, al meglio che puoi proiettare.
- Forse, ma non sempre, un elenco di date e orari UTC di eventi futuri, proiettato in un periodo predefinito nel futuro (forse una settimana, forse 6 mesi, forse un anno o due, a seconda delle tue esigenze).
Per gli ultimi due, comprendi che l'equivalente UTC di qualsiasi data/ora locale può cambiare se il governo responsabile di quel fuso orario decide di cambiare qualcosa. Poiché ci sono più aggiornamenti del database dei fusi orari ogni anno, ti consigliamo di avere un piano per iscriviti agli annunci di aggiornamenti e aggiorna il database dei fusi orari regolarmente. Ogni volta che aggiorni i dati del tuo fuso orario, dovrai ricalcolare gli orari equivalenti UTC di tutti gli eventi futuri.
Avere gli equivalenti UTC è importante se prevedi di mostrare qualsiasi tipo di elenco di eventi che copre più di un fuso orario. Questi sono i valori che interrogherai per creare quell'elenco.
Un altro punto da considerare è che se un evento è programmato per un'ora locale che si verifica durante una transizione di riserva dell'ora legale, dovrai decidere se l'evento si verifica in prima istanza (di solito) o in seconda istanza (a volte), o entrambi (raramente) e incorpora nella tua applicazione un meccanismo per garantire che l'evento non si attivi due volte a meno che tu non lo desideri.
Se stavi cercando una risposta semplice, scusa, ma non ce n'è una. La pianificazione di eventi futuri in più fusi orari è un compito complicato.
Approccio alternativo
Alcune persone mi hanno mostrato una tecnica in cui fanno utilizzare l'ora UTC per la pianificazione, ovvero selezionare una data di inizio nell'ora locale, convertirla in UTC per essere archiviata e memorizzare anche l'ID del fuso orario. Quindi, in fase di esecuzione, applicano il fuso orario per riconvertire l'ora UTC originale nell'ora locale, quindi utilizzano quell'ora locale per calcolare le altre ricorrenze, come se fosse quella originariamente memorizzata come sopra.
Anche se questa tecnica funziona , gli svantaggi sono:
-
Se è presente un aggiornamento del fuso orario che modifica l'ora locale prima dell'esecuzione della prima istanza, annullerà l'intera pianificazione. Questo può essere mitigato scegliendo un tempo passato per la "prima" istanza, in modo tale che la seconda istanza sia davvero la prima.
-
Se l'ora è davvero un "tempo fluttuante" che dovrebbe seguire l'utente in giro (come in una sveglia su un telefono cellulare), dovresti comunque memorizzare le informazioni sul fuso orario per la zona in cui è stato originariamente creato, anche se non è la zona in cui vuoi correre.
-
Aggiunge ulteriore complessità senza alcun vantaggio. Riserverei questa tecnica per le situazioni in cui potresti aver avuto uno scheduler solo UTC in cui stai cercando di adattare il supporto del fuso orario.
