Tout d'abord, veuillez reconnaître que dans la terminologie moderne, vous devriez dire UTC au lieu de GMT. Ils sont pour la plupart équivalents, sauf que UTC est défini plus précisément. Réservez le terme GMT pour désigner la partie du fuseau horaire du Royaume-Uni en vigueur pendant les mois d'hiver ayant le décalage UTC+0.
Passons maintenant à votre question. UTC n'est pas nécessairement le meilleur moyen de stocker toutes les valeurs de date et d'heure. Cela fonctionne particulièrement bien pour le passé événements, ou pour le futur absolu événements, mais cela ne fonctionne pas très bien pour les futurs locaux événements - en particulier futurs récurrents événements.
J'ai écrit à ce sujet sur une autre réponse récemment, et est l'un des rares cas exceptionnels où l'heure locale a plus de sens que l'UTC. L'argument principal est le "problème du réveil". Si vous réglez votre réveil sur UTC, vous vous réveillerez une heure plus tôt ou plus tard le jour des transitions DST. C'est pourquoi la plupart des gens règlent leur réveil à l'heure locale.
Bien sûr, vous ne pouvez pas juste stocker une heure locale si vous travaillez avec des données du monde entier. Vous devriez stocker quelques éléments différents :
- L'heure locale de l'événement récurrent, par exemple "08:00"
- Le fuseau horaire dans lequel l'heure locale est exprimée, par exemple "America/New_York"
- Le modèle de récurrence, quel que soit le format adapté à votre application, tel que quotidien, bihebdomadaire ou le troisième jeudi du mois, etc.
- Le prochain immédiat Équivalent de la date et de l'heure UTC, au mieux que vous puissiez projeter.
- Peut-être, mais pas toujours, une liste des dates et heures UTC futures des événements, projetées sur une période prédéfinie dans le futur (peut-être une semaine, peut-être 6 mois, peut-être un an ou deux, selon vos besoins).
Pour les deux derniers, comprenez que l'équivalent UTC de toute date/heure locale peut changer si le gouvernement responsable de ce fuseau horaire décide de changer quoi que ce soit. Puisqu'il y a plusieurs mises à jour de la base de données de fuseaux horaires chaque année, vous voudrez avoir un plan pour abonnez-vous aux annonces de mises à jour et mettre à jour votre base de données de fuseaux horaires de façon régulière. Chaque fois que vous mettez à jour vos données de fuseau horaire, vous devrez recalculer les heures UTC équivalentes de tous les événements futurs.
Avoir les équivalents UTC est important si vous prévoyez d'afficher n'importe quel type de liste d'événements couvrant plus d'un fuseau horaire. Ce sont les valeurs que vous interrogerez pour créer cette liste.
Un autre point à considérer est que si un événement est programmé pour une heure locale qui se produit pendant une transition de repli DST, vous devrez décider si l'événement se produit sur la première instance (généralement) ou la seconde instance (parfois), ou les deux (rarement), et intégrez à votre application un mécanisme pour vous assurer que l'événement ne se déclenche pas deux fois, sauf si vous le souhaitez.
Si vous cherchiez une réponse simple - désolé, mais il n'y en a pas. Planifier des événements futurs sur plusieurs fuseaux horaires est une tâche compliquée.
Approche alternative
J'ai eu quelques personnes qui m'ont montré une technique où elles font utiliser l'heure UTC pour la planification, c'est-à-dire qu'ils choisissent une date de début en heure locale, la convertissent en UTC pour la stocker et stockent également l'ID de fuseau horaire. Ensuite, lors de l'exécution, ils appliquent le fuseau horaire pour reconvertir l'heure UTC d'origine en heure locale, puis utilisent cette heure locale pour calculer les autres récurrences, comme s'il s'agissait de celle stockée à l'origine comme ci-dessus.
Même si cette technique fonctionnera , les inconvénients sont :
-
S'il y a une mise à jour du fuseau horaire qui change l'heure locale avant l'exécution de la première instance, cela annulera tout le calendrier. Cela peut être atténué en choisissant une heure dans le passé pour la "première" instance, de sorte que la deuxième instance soit vraiment la première.
-
Si l'heure est vraiment une "heure flottante" qui devrait suivre l'utilisateur (comme dans un réveil sur un téléphone portable), vous devrez toujours stocker les informations de fuseau horaire pour la zone dans laquelle elle a été créée à l'origine - même si ce n'est pas la zone dans laquelle vous voulez courir.
-
Cela ajoute une complexité supplémentaire sans aucun avantage. Je réserverais cette technique pour les situations où vous avez peut-être eu un planificateur UTC uniquement dans lequel vous essayez d'adapter la prise en charge du fuseau horaire.
