Fermer

août 14, 2020

ISO 8601 Date heure Corticon.js mobile sans serveur


Découvrez comment utiliser la date et l'heure ISO 8601 dans la charge utile Corticon.js pour les fonctions cloud sans serveur, les applications mobiles et les navigateurs.

Dans un précédent blog— Traiter la date et l'heure avec Corticon.js —Nous avons discuté des problèmes de date et d'heure dans les systèmes distribués. Nous avons vu les utilisations de l'UTC et nous avons commencé à parler du format date / heure ISO 8601 comme l'un des formats acceptés dans la charge utile JSON des services de décision.

Ce sont des problèmes et des concepts importants à comprendre en particulier dans un monde d'applications de navigateurs, application mobile et fonctions sans serveur dans le cloud,

Dans ce blog, nous approfondirons nos connaissances en passant en revue le format ISO 8601 plus en détail. Le public visé est celui des intégrateurs de services de décision, et ce n'est pas pour les auteurs de règles.

Formats ISO 8601

Les formats date / heure peuvent prêter à confusion car les différents paramètres régionaux du monde ont tendance à représenter la date et l'heure différemment. Le plus déroutant est le fait que certains paramètres régionaux échangent la position du mois, par exemple, 8/4/2020 peut être interprété comme le 8 avril ou le 4 août.

ISO 8601 représente la date et l'heure en commençant par année, suivi du mois, du jour, de l'heure, des minutes, des secondes et des millisecondes.

Par exemple, 2020-07-10 15: 00: 00.000, représente le 10 juillet 2020 à 15 heures (en heure locale car aucun décalage de fuseau horaire n'est spécifié – plus d'informations ci-dessous).

Il existe de nombreuses variantes par lesquelles une date et une heure peuvent être représentées sous la forme ISO 8601. Vous trouverez ci-dessous une explication des principales chaînes ISO 8601. .

Une chaîne ISO 8601 nécessite une partie de date mais la partie de temps est facultative

08/02/2020 – Dans cet exemple, nous avons juste une partie de date de calendrier et aucune partie de temps (02 est Février).

Il existe des formats inhabituels mais très utiles, comme:

2020-W06-5 – Cet exemple a une partie de date de semaine: il indique Semaine 6, Jour 5 de 2020. Assez cool et utile. 🙂

2020-039 – Cet exemple a une partie de date ordinale: il indique le jour 39 de 2020. Très utile aussi.

Vous pouvez spécifier une version courte de ce qui précède comme ceci: [19659003] 20200208 – Exemple avec date complète courte.

2020W065 – Exemple avec semaine courte, spécification du jour de la semaine.

2020W06 – Exemple avec semaine courte uniquement.

2020039 – Exemple avec date ordinale courte.

Une partie heure peut également être incluse

La partie heure est séparée de la partie date par un espace ou une majuscule T.

2020-02-08T09 – Exemple avec une partie heure heure séparée par un T. Il s'agit de 9 heures

2020-02-08 09 – Même exemple avec heure heure partie séparée par un espace.

2020-02-08 09:30 – Exemple avec une partie heure et minute. Il est 9h30 du matin

2020-02-08 09:30:26 – Exemple avec heure, minute et deuxième tranche horaire.

2020-02-08 09: 30: 26.123 – Exemple avec heure, minute, seconde et milliseconde.

Il existe également des expressions courtes:

20200208T080910,123 – Exemple avec date et heure courtes jusqu'à ms, séparés par des virgules.

20200208T080910.123 – Exemple avec date et heure courtes jusqu'à ms.

20200208T080910 – Exemple avec date et heure courtes jusqu'à quelques secondes.

20200208T0809 – Exemple avec date et heure courtes jusqu'à quelques minutes.

20200208T08 – Exemple avec date et heure courtes, heures uniquement.

L'une des parties de date Peut avoir une partie de l'heure

2020-W06-5 09 – Exemple avec une partie de la date de la semaine: Jour 5 de la semaine 6 à 9 h

2020-039 09 – Exemple avec partie de date ordinale et heure tim Partie: Jour 39 de 2020 à 9 h

Décalage du fuseau horaire dans la partie temporelle

Il est important dans un monde d'applications de navigateurs, d'applications mobiles et de fonctions sans serveur dans le cloud, de comprendre les fuseaux horaires.

Si une partie de temps est incluse, un décalage par rapport à UTC peut également être inclus en utilisant l'un de ces quatre formats:

  1. + – HH: mm
  2. + – HHmm
  3. + – HH
  4. Z.

2020 -02-08 09 + 07: 00 – Au format + -HH: mm Cette date est décalée de sept heures par rapport à UTC. En d'autres termes, il est à 9 heures du matin dans le fuseau horaire +7.

2020-02-08 09-0100 – Au format # + -HHmm Cette date a un décalage de -1 heure par rapport à UTC.

2020-02-08 09Z – Au format Z Cette date n'a pas de décalage par rapport à UTC (ou décalage de 0 heure).

Remarque: Les minutes des fuseaux horaires ne sont pas nécessairement 0. Certains fuseaux horaires peuvent contenir un décalage de minutes valide. Par exemple: Terre-Neuve au Canada utilise l'heure normale de Terre-Neuve (NST) qui a un décalage de UTC – 3:30. Pendant l'heure d'été, la zone passe à un décalage de UTC – 2:30.

Le Népal a 15 minutes d'avance sur le fuseau horaire de l'Inde. Cela signifie que lorsqu'il est minuit UTC, il est 5 h 45 au Népal.

Voir https://www.worldtimeserver.com/learn/unusual-time-zones/ pour plus d'infos

Quelle heure est utilisée lorsqu'aucune partie d'heure n'est spécifiée

Si aucune partie d'heure n'est spécifiée, elles sont réglées par défaut au début de la journée dans le fuseau horaire local. Une autre façon de mettre cela est, si aucune partie de l'heure n'est spécifiée, l'objet date / heure est construit comme si l'heure était 00: 00: 00.000.

Notez que l'objet est construit en fonction du fuseau horaire local où le service de décision est en cours d'exécution. Cela peut conduire à des résultats différents selon l'endroit où le service de décision est en cours d'exécution (par exemple entre un serveur de nœuds fonctionnant sur site et une fonction sans serveur dans le cloud).

Cela peut ne pas être un problème pour vous dans certains cas, mais dans d'autres cas, cela pourrait rendre les choses difficiles à dépanner. Ainsi, pour éviter toute confusion, nous recommandons que l'appelant d'un service de décision spécifie une période pour lever l'ambiguïté.

Par exemple: 2020-04-30 sera construit comme si la date et l'heure étaient passées comme 2020-04-30T00: 00: 00.000 (et pas comme si passé comme 2020-04-30T00: 00: 00.000 Z )

Donc en utilisant cette date le: [19659039] Les fonctions AWS Lambda ou Azure donnent le résultat "2020-04-30T 00 : 00: 00.000Z". Les fonctions de cloud sans serveur sont en UTC.

  • Le nœud sur la machine locale sur la côte est des États-Unis (fuseau horaire EST) donne "2020-04-30T 04 : 00: 00.000Z" (4 / 30/2020 avec heure d'été sur a -4 heures de différence avec UTC sur la côte est des États-Unis).
  • Comme vous pouvez le voir, cela peut être indésirable dans certaines situations, donc encore une fois, pour éviter toute ambiguïté, nous vous recommandons de spécifier une période

    En conclusion, ISO 8601 est une norme qui offre beaucoup de flexibilité. Il est utile de connaître ses capacités pour bien s'intégrer avec d'autres services ou avec des clients qui doivent afficher la date et l'heure à l'utilisateur.

    Vous pouvez en savoir plus à ce sujet sur https://en.wikipedia.org/wiki /ISO_8601[19459007</font>




    Source link