Fonctions sans serveur de date / heure et Corticon.js

Dans ce blog, nous explorerons la complexité du traitement de la date / heure en général et en particulier des fonctions sans serveur (fonctions Lambda ou Azure).

Nous parlerons de la coordonnée de temps universel (UTC) et nous allons également regardez comment passer des valeurs de date / heure dans une charge utile JSON du service de décision Corticon.js.

Ce message est destiné aux utilisateurs qui intègrent des services de décision avec d'autres systèmes; il n'est pas destiné aux auteurs de règles.

Problèmes relatifs à la date / heure

Il existe de nombreux problèmes liés au traitement des dates-heures et des systèmes distribués en général (clients distribués ainsi que services de décision distribués):

• Nous ne peut faire aucune hypothèse sur l'emplacement d'un service de décision. En effet, il pourrait être déployé dans un centre de données sur la côte Est des États-Unis ou en Europe ou en Asie, etc.
• Les demandes des clients peuvent également provenir de différents fuseaux horaires.
• Lors de la mise en œuvre d'applications composites, le divers services invoqués peuvent être exécutés dans différents fuseaux horaires et également utiliser différents formats de date. Un exemple d'application composite simple serait un événement dans AWS Cloud ou Azure déclenche l'exécution de quelques appels REST, les données de ces appels sont composées dans une charge utile et transmises à un ensemble de services de décision.

Voici un diagramme rapide montrant la complexité du traitement des clients distribués ainsi que des services de décision distribués.

Ce scénario pourrait être, par exemple, un service de location de voiture où les dates échangées sont la date de la réservation et la date / heure de disponibilité du véhicule. [19659002] La pire erreur de configuration de serveur que vous pouvez faire et Toujours utiliser les dates et heures UTC

En passant, il existe des similitudes entre UTC et GMT, mais techniquement elles sont différentes. Voir UTC – The World's Time Standard pour plus de données de fond et les différences entre UTC et GMT.

Format in JSON Payload

UTC nous permet de nous mettre d'accord sur une coordonnée temporelle spécifique, mais il ne spécifie pas le format pour représenter la date / heure dans une demande ou une réponse.

JSON ne standardise pas la façon de représenter les dates et les heures. Les formats les plus courants que nous avons vus utilisés dans les services, en particulier les services REST, sont ISO 8601 et en nombre (nombre de millisecondes depuis l'époque). Ainsi, afin de vous faciliter la vie, nous avons décidé de prendre en charge ces deux formats dès la sortie de la boîte.

Dans la charge utile JSON, les données de date / heure peuvent être spécifiées comme suit:

1. 1. Un format de date ISO 8601 sous forme de chaîne. Nous aborderons ce format plus en détail dans un blog séparé. Vous pouvez consulter https://en.wikipedia.org/wiki/ISO_8601 pour une référence.
2. 2. Une valeur longue, représentant le temps écoulé depuis l'époque en ms (horodatage en millisecondes). Il peut être passé sous forme de chaîne ou de nombre. Voir https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTime ) Ce format n'est pas facilement lisible, vous pouvez utiliser cet outil, par exemple : https://www.epochconverter.com/ pour obtenir une représentation à l'heure locale.

Par exemple, voici comment passer la date / heure (UTC) «Jeudi 30 juillet 2020 6:00:00 PM ”dans la charge utile JSON du service de décision:

1. 2020-07-30T18: 00: 00.000Z
   Ceci représente la date / heure comme ISO 8601 directement à la référence UTC (que aucun fuseau horaire n'est spécifié).
2. 2020-07-30T14: 00: 00.000-04
   Ceci représente la même date / heure que ISO 8601 avec un fuseau horaire (notez au lieu de 18 heures c'est 14). Nous acceptons ce format comme entrée mais ne renverrons pas les résultats dans cette notation.
3. 1596132000000
   La même date / heure que le nombre de ms depuis l'époque
4. «1596132000000» [19659032] Identique au précédent mais sous forme de chaîne. Nous soutenons cela par commodité et pour éviter les confusions.

Donc, pour résumer, voici quelques points à garder à l'esprit:

1. Le moteur Corticon.js effectue tous ses calculs en utilisant UTC comme référence de temps. [19659007] Le moteur Corticon.js renverra toujours DateTime en UTC et au format ISO 8601 quel que soit le format d'entrée que vous avez utilisé (pour les options d'entrée, voir la section suivante où nous parlons de fuseaux horaires).

Traiter les fuseaux horaires

Voici les paramètres clés à prendre en compte lorsque vous pensez à TZ:

• Des fonctions sans serveur identiques peuvent être exécutées dans différents centres de données avec différentes TZ
• Azure ou Lambda sont configurés pour s'exécuter de toute façon en UTC
• Deux interfaces utilisateur client peuvent fonctionner dans différents TZ
• Les utilisateurs mobiles, utilisant la même application peuvent voyager à un endroit différent. Ils s'attendent à ce que l'application continue de fonctionner correctement.
• Encore plus délicat, la sortie d'un service de décision pourrait être utilisée comme entrée vers une autre API (REST, Serverless ou autres) résidant dans une TZ différente.

À la fin de le jour, les services de décision font partie d'une vue d'ensemble et l'intégrateur doit faire face à TZ quoi qu'il arrive. Nous n’ajoutons pas vraiment de nouveau problème ici. Nous définissons des règles simples selon lesquelles les dates et les heures fonctionneront correctement.

Maintenant que vous comprenez les problèmes liés à la date, nous vous recommandons de travailler avec les dates UTC et de ne vous adapter qu'au fuseau horaire de l'utilisateur local juste avant de les afficher. [19659002] Pour vous simplifier la vie, nous vous proposons deux options:

1. Convertir toutes les dates / heures en UTC avant d'écrire dans la charge utile (par exemple, 2020-07-30T18: 00: 00.000Z) ..
2. 2 . Passez la date / heure avec un décalage TZ (par exemple, 2020-07-30T14: 00: 00.000-04), Corticon.js reconnaîtra la TZ et construira la date / heure UTC de manière appropriée.

Indépendamment de l'option choisie, la date / heure du résultat JSON sera renvoyée en UTC. Il vous reste la tâche de convertir le fuseau horaire local des différents appareils où la date et l'heure sont rendues. Bien sûr, cela suppose que le résultat est directement utilisé dans une interface utilisateur, si vous enchaînez un service de décision à un autre, vous n'aurez probablement pas besoin de faire de conversion.

En conclusion, il est difficile de traiter la date / l'heure. Nous avons essayé de simplifier la vie d'un intégrateur en:

1. Standardisant les calculs et la sortie du service de décision UTC. Cela simplifie beaucoup les choses et évite de nombreux problèmes de dépannage.
2. Vous permet toujours de transmettre la date / heure comme entrée en UTC ou avec un décalage de fuseau horaire.
3. Offrant deux formats standardisés différents pour la date / heure représentation dans les données JSON. Cela devrait offrir de la flexibilité lors du maillage des services de décision avec d'autres services.

J'espère que cela vous sera utile pour intégrer vos services de décision dans vos applications et, surtout, pour les déboguer et les maintenir.

N'hésitez pas à laisser une question ci-dessous pour toute question supplémentaire que vous pourriez avoir.

Dans un prochain article de blog, nous discuterons du format date / heure ISO 8601.