Imaginons un instant que vous soyez un espion d'action international qui a consacré sa vie à protéger les peuples du monde du danger. Vous recevez la mission suivante :
Bonjour, Agent IRIS,
Nous sommes désolés d'interrompre vos vacances aux Bahamas, mais nous venons de recevoir un message de notre agent londonien nous informant qu'une "bombe à retardement" est sur le point d'exploser dans une zone très peuplée de Los Angeles. Selon nos sources, la "bombe à retardement" devrait se déclencher à 15h14 cet après-midi.
Dépêchez-vous, les gens comptent sur vous !
Vous vous levez précipitamment et vous préparez à partir pour Los Angeles, mais vous vous rendez vite compte qu'il vous manque une information clé ; la « bombe à retardement » se déclenchera-t-elle à 15h14, heure de Bahama ou à 15h14, heure de Los Angeles ? ...ou peut-être même 15h14, heure de Londres.
Vous vous rendez vite compte que l'heure qui vous a été indiquée (15h14) ne vous donne pas suffisamment d'informations pour déterminer quand vous devez être à Los Angeles.
L'heure qui vous a été indiquée (15h14) était ambiguë. Vous avez besoin de plus d’informations pour déterminer une heure exacte.
En réfléchissant au problème, vous réalisez qu'il existe des méthodes pour surmonter l'ambiguïté du temps qui vous a été fourni :
Votre source aurait pu fournir l'endroit où il était 15h14. Par exemple, Los Angeles, les Bahamas ou Londres.
Votre source aurait pu utiliser une norme telle que UTC (temps universel coordonné) pour vous fournir un décalage par rapport à un emplacement convenu (comme Greenwich, Londres).
Vous appelez votre source et confirmez que l'heure indiquée était bien 15h14, heure de Los Angeles. Vous pouvez voyager à Los Angeles, désamorcer la « bombe à retardement » avant 15h14 et retourner rapidement aux Bahamas pour terminer vos vacances.
Alors, quel est l’intérêt de cet exercice de réflexion ? Je doute que l'un d'entre nous rencontre le problème présenté ci-dessus, mais si vous travaillez avec une application ou un code qui déplace des données d'un emplacement à un autre (surtout si les emplacements sont dans des fuseaux horaires différents), vous devez en être conscient. sur la façon de gérer les dates, heures et fuseaux horaires.
Eh bien, les fuseaux horaires ne sont pas si mauvais. L’heure d’été et les frontières politiques rendent les fuseaux horaires difficiles.
Je pensais avoir toujours compris l'idée "générale" des fuseaux horaires : la planète est divisée en tranches verticales par fuseau horaire, où chaque fuseau horaire est en retard d'une heure sur le fuseau horaire à l'Est.
Bien que cette simplification s'applique à de nombreux endroits, il existe malheureusement de nombreuses exceptions à cette règle.
Référence : Fuseaux horaires du monde (Wikipédia)
Pour simplifier le langage de transmission d'heures spécifiques, le monde a opté pour l'utilisation de l'UTC (temps universel coordonné). Cette norme fixe « l'origine » à la longitude 0° qui passe par Greenwich, Londres.
En utilisant UTC comme base, tous les autres fuseaux horaires peuvent être définis par rapport à UTC. Cette relation est appelée décalage UTC.
Si vous avez une heure locale et un décalage, vous n'avez plus d'heure ambiguë (comme on le voit dans notre exemple d'espionnage ci-dessus) ; vous avez une heure définie et précise sans ambiguïté.
Le format typique utilisé pour afficher le décalage UTC est ±HHMM[SS[.ffffff]].
Par exemple, en Amérique, la zone Eastern Standard Zime (EST) est définie comme -0500 UTC. Cela signifie que tous les emplacements en EST ont 5 heures de retard sur UTC. S'il est 21h00 à UTC, alors l'heure locale à EST est 16h00.
Dans le fuseau horaire standard du centre-ouest de l'Australie (ACWST), le décalage est défini comme 0845 UTC. S'il est 1h00 à UTC, alors l'heure locale à ACWST est 9h45.
Revenons donc aux cartes de fuseaux horaires ci-dessus. Sur l’image, vous pouvez voir que de nombreux fuseaux horaires suivent les frontières politiques des pays et des régions. Cela complique légèrement les calculs de fuseau horaire, mais c'est assez simple à comprendre.
Malheureusement, il y a un autre facteur à prendre en compte lorsque vous travaillez avec des heures et des fuseaux horaires.
Regardons Los Angeles.
Sur la carte, le décalage UTC pour Los Angeles est de -8 en Heure standard. L'heure normale est généralement suivie pendant les mois d'hiver, tandis que l'heure d'été est généralement suivie pendant les mois d'été.
L'heure d'été (DST) avance les horloges d'un fuseau horaire donné (généralement d'une heure pendant les mois d'été). Il existe plusieurs raisons pour lesquelles les régions politiques pourraient choisir de suivre l'heure d'été (telles que les économies d'énergie, une meilleure utilisation de la lumière du jour, etc.). La difficulté et la complexité de l’heure d’été sont que l’heure d’été n’est pas systématiquement respectée dans le monde entier. Selon votre emplacement, votre région peut ou non suivre l'heure d'été.
Étant donné que la combinaison des frontières politiques et de l’heure d’été augmente considérablement la complexité de la détermination d’une heure spécifique, une base de données de fuseaux horaires est nécessaire pour mapper correctement les heures locales aux heures spécifiques par rapport à UTC. La base de données de fuseau horaire de l'IANA (Internet Assigned Numbers Authority) est la source commune d'informations sur le fuseau horaire utilisée par les systèmes d'exploitation et les langages de programmation.
La base de données comprend les noms et alias de tous les fuseaux horaires, des informations sur le décalage, des informations sur l'utilisation de l'heure d'été, les abréviations des fuseaux horaires et les plages de dates auxquelles les différentes règles s'appliquent.
Des copies et des informations sur la base de données des fuseaux horaires peuvent être trouvées sur le site Web de l'IANA.
La plupart des systèmes UNIX disposent d'une copie de la base de données qui est mise à jour avec le gestionnaire de packages du système d'exploitation (généralement installé dans /usr/share/zoneinfo). Certains langages de programmation intègrent la base de données. D'autres le mettent à disposition par une bibliothèque ou peuvent lire la copie du système de la base de données.
La base de données des fuseaux horaires contient de nombreux noms et alias pour des fuseaux horaires spécifiques. De nombreuses entrées incluent un pays (ou un continent) et une grande ville dans le nom. Par exemple :
Donc, maintenant nous savons :
Sachant cela, comment travaillons-nous avec les dates/heures/fuseaux horaires dans ObjectScript ?
***Remarque : je pense que toutes les déclarations suivantes sont vraies à propos d'ObjectScript, mais veuillez me faire savoir si j'indique mal la manière dont ObjectScript fonctionne avec les fuseaux horaires et les décalages.
Si vous devez convertir des horodatages entre différents formats dans le fuseau horaire système du processus exécutant IRIS, les fonctionnalités intégrées d'ObjectScript devraient être suffisantes. Voici une brève liste de diverses variables/fonctions liées au temps dans ObjectScript :
$ZTIMESTAMP / $ZTS
$MAINTENANT(tzmins)
$HOROLOGIE
$ZTIMEZONE
$ZDATETIME() / $ZDT()
$ZDATETIMEH() / $ZDTH()
Autant que je sache, ces fonctions ne sont capables de manipuler les dates et heures qu'en utilisant le fuseau horaire du système local. Il ne semble pas y avoir de moyen de travailler avec des fuseaux horaires arbitraires dans ObjectScript.
Pour permettre la conversion vers et depuis des fuseaux horaires arbitraires, j'ai travaillé à la création de la bibliothèque de conversion de fuseau horaire tz - ObjectScript.
Cette bibliothèque accède à la base de données de fuseaux horaires installée sur votre système pour prendre en charge la conversion des horodatages entre les fuseaux horaires et les formats.
Par exemple, si vous avez l'heure locale de Los Angeles (Amérique/Los_Angeles), vous pouvez la convertir dans le fuseau horaire utilisé aux Bahamas (Amérique/New_York) ou dans le fuseau horaire utilisé à Londres (Europe/Londres) :
USER>zw ##class(tz.Ens).TZ("2024-12-20 3:14 PM", "America/Los_Angeles", "America/New_York") "2024-12-20 06:14 PM" USER>zw ##class(tz.Ens).TZ("2024-12-20 3:14 PM", "America/Los_Angeles", "Europe/London") "2024-12-20 11:14 PM"
Si vous recevez un horodatage avec un décalage, vous pouvez le convertir à l'heure locale d'Eucla, Australie (Australie/Eucla), même si vous ne connaissez pas le fuseau horaire d'origine :
USER>zw ##class(tz.Ens).TZ("2024-12-20 08:00 PM -0500", "Australia/Eucla") "2024-12-21 09:45 AM +0845"
Si vous travaillez avec des messages HL7, la bibliothèque tz dispose de plusieurs méthodes exposées aux règles d'interopérabilité et aux DTL pour vous aider à convertir facilement entre les fuseaux horaires, les heures locales, les heures avec décalages, etc. :
// Convert local time from one time zone to another set datetime = "20240102033045" set newDatetime = ##class(tz.Ens).TZ(datetime,"America/New_York","America/Chicago") // Convert local time to offset set datetime = "20240102033045" set newDatetime = ##class(tz.Ens).TZOffset(datetime,"America/Chicago","America/New_York") // Convert offset to local time set datetime = "20240102033045-0500" set newDatetime = ##class(tz.Ens).TZLocal(datetime,"America/Chicago") // Convert to a non-HL7 format set datetime = "20240102033045-0500" set newDatetime = ##class(tz.Ens).TZ(datetime,"America/Chicago",,"%m/%d/%Y %H:%M:%S %z")
J'apprécie que vous me suiviez dans ce "voyage international" où nous avons rencontré des fuseaux horaires, l'heure d'été, des cartes du monde et des "bombes à retardement". Espérons que cela ait pu faire la lumière (et simplifier) de nombreuses complexités liées au travail avec les dates-heures et les fuseaux horaires.
Consultez tz - Bibliothèque de conversion de fuseau horaire ObjectScript et faites-moi savoir si vous avez des questions (ou des corrections/clarifications à quelque chose que j'ai dit).
Merci !
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!