Puisque vous parlez de planification du futur temps, stockage uniquement UTC n'est pas nécessairement la meilleure approche.
Gardez à l'esprit que les règles de fuseau horaire peuvent changer (et changent). Si vous appliquez une mise à jour de vos données de fuseau horaire (en PHP, cela se fait avec le timezonedb de PECL package), alors toutes les données que vous avez déjà converties en UTC peuvent être invalides.
La meilleure solution consiste à stocker plusieurs valeurs :
-
La date et l'heure locales d'origine
-
Le fuseau horaire d'origine (ex.
"America/New_York") -
La date et l'heure UTC, converties à partir des valeurs locales
Lorsque vous voulez voir s'il est temps d'exécuter la tâche, vous devez comparer la date et l'heure UTC actuelles avec la valeur UTC stockée.
Lorsque vous appliquez des mises à jour de fuseau horaire, vous jetez les valeurs UTC converties précédentes pour toutes les entrées futures et recalculez les nouvelles en fonction des données mises à jour.
Si vous ne le faites pas, vous perdez l'intention initialement fournie par l'utilisateur. Et si vous ne mettez pas à jour vos données de fuseau horaire, votre système ne sera pas au courant des divers changements qui se produisent dans le monde, tels que les changements apportés en Égypte plus tôt cette année ou les changements à venir en octobre pour la Russie.
Dernier point - S'il est correctement implémenté, le fuseau horaire de votre serveur ne devrait pas avoir d'importance. Comparez UTC à UTC.
