des valeurs dans les flux Architect et les calculs de l’heure d’été (DST)

Architect traite de manière native le temps universel coordonné (UTC) pour valeurs. En ce qui concerne la conversion d’un UTC à un local pour un fuseau horaire spécifique, les auteurs de flux doivent créer une logique à l’intérieur du flux pour effectuer cette conversion, car Architect n’inclut pas actuellement de type de données de fuseau horaire pouvant être utilisé pour fournir un décalage et un biais DST.

Par exemple, notez que le Flow.StartDateTimeUtc variable et la GetCurrentDateTimeUtc () retour de fonction valeurs en UTC. Architect propose différentes fonctions et opérateurs d’expression pour aider un auteur de flux à manipuler valeurs pour répondre aux besoins d’un auteur de flux. Une question courante des auteurs de flux est « Comment puis-je convertir un valeur pour qu’elle reflète l’UTC dans un fuseau horaire spécifique ? ”car ils veulent modifier l’exécution du flux en fonction de l’heure locale. Cette question peut se poser lorsque, dans un flux d ’ appels, vous souhaitez uniquement diriger un appel vers une file d’attente entre 9h00 et 17h00, heure locale.

Fonctions couramment utilisées pour appliquer un décalage à un et renvoyer un résultat valeur comprennent :

  • AddHours
  • AddMinutes

Certains opérateurs peuvent également être utilisés pour modifier une valeur. Par exemple, utilisez le signe + pour ajouter une durée à une et obtenir un résultat ainsi que.

Les exemples suivants montrent des façons de calculer une valeur locale valeur d’un UTC et peut être modifié selon ce qui convient le mieux à votre organisation.

Dans cette approche de base, un auteur de flux peut stocker un décalage dans une variable de niveau de flux et l’appliquer à UTC. valeurs utilisées dans les calculs de flux. Dans l’exemple suivant, le décalage est stocké dans Flow.HourOffset:

Flow.LocalDateTime = AddHours(GetCurrentDateTimeUtc(), Flow.HourOffset)

Lorsqu'un fuseau horaire avance ou recule, modifiez la valeur dans Débit.HourOffset et republier le flux. Cette logique simple peut être suffisante pour votre organisation. Certains fuseaux horaires ; Par exemple, en Arizona et à Hawaii, ne faites pas une chute en avant ou en avant, un décalage codé en dur suffit donc.

De plus, certains fuseaux horaires avancent ou reculent de 30 minutes au lieu d’une heure. Dans ces cas, utilisez AddMinutes au lieu de AddHours pour appliquer le décalage approprié. Si vous avez une heure locale qui traite de l'heure d'été, modifiez la valeur stockée dans la variable utilisée pour le décalage comme il convient lorsque l'heure avance ou recule. Dans l’exemple ci-dessus, cela signifie que vous devez modifier la valeur dans Flow.HourOffset et republier le flux lorsque le temps s’écoule ou diminue.

Pour éviter à tâche de republier le flux lorsque fuseau horaire avance ou recule, comme dans l’exemple précédent, vous pouvez utiliser des variables de collection pour prendre en compte les décalages d’un fuseau horaire. Bien que cette option nécessite initialement davantage de travail, elle élimine la nécessité de gérer les décalages stockés dans des variables de niveau de flux et offre plus de simplicité que l’utilisation d’expressions.

Cette méthode utilise une approche de tableau parallèle et enregistre les décalages souhaités qui prennent en compte le décalage de biais pour un fuseau horaire donné à une heure UTC. valeur. Cet exemple est une configuration de variables de collection d’entiers pour le fuseau horaire de l’Est calculs de valeur. 

Remarque :  Le décalage est de -5 heures. Appliquez manuellement le biais de l’heure d’été aux entrées des éléments Flow.LocalTimeZoneMinuteOffsetCollection selon le cas.
Article de collection Flow.UtcDateTimeCollection Flow.LocalTimezoneMinuteOffsetCollection
Point 0 Dimanche 13 mars 2016 à 7h00

-300 

Remarque :  Remarque: -300 représente -300 minutes ou -5 heures.
Objet 1 Dimanche 6 novembre 2016 à 8h00

-240

Remarque :   -240 représente -240 minutes ou -4 heures. Dans ce cas, après le dimanche 13 mars 2016 à 7h00 UTC (le premier article de la collection) jusqu'au dimanche 6 novembre 2016 à 8h00 UTC, le système doit décaler une valeur DateTime UTC de -240 minutes, ce qui garantit qu'il est à l'heure locale correcte.
Point 2 Dimanche 12 mars 2017 à 7h00 -300
Point 3 Dimanche 5 novembre 2017 à 8h00 -240
Point 4 Dimanche 11 mars 2018 à 7h00 -300
Point 5 Dimanche 4 novembre 2018 à 8h00 -240
Point 6 Dimanche 10 mars 2019 à 7h00 -300
Point 7 Dimanche 3 novembre 2019 à 8h00 -240
Point 8 Dimanche 8 mars 2020 à 7h00 -300
Point 9* Dimanche 1er novembre 2020 à 8h00 -240

* Ajoutez plus d’entrées pour les flux d’appels ayant dépassé l’année 2020.

Cette collection est un ensemble de UTC valeurs pour le moment où fuseau horaire de l’Est avance ou recule. Construisez maintenant une tâche qui, lorsqu’un flux commence, recherche une heure locale en fonction des considérations DST et fuseau horaire :

  1. Déterminer le UTC valeur pour laquelle l’auteur du flux souhaite obtenir une adresse locale . Par exemple, utilisez une action Update Data ou Flow.StartDateTimeUtc pour sauvegarder off GetCurrentDateTimeUtc () vers Flow.UtcDateTimeToCheck, ou dans ce cas, utilisez Flow.StartDateTimeUtc.
  2. Ajouter et configurer une action de boucle :
    1. À partir de l’index 0, parcourez le Flow.UTCDateTimeCollection.
    2. Pour la première valeur trouvée dans Flow.UTCDateTimeCollection Suérieur ou égal à Flow.UtcDateTimeToCheck, sauvegardez le décalage en minutes correspondant au même index d'éléments Flow.LocalTimezoneMinuteOffsetCollection à Flow.MinuteOffsetToApply.
  3. Après la boucle, si aucune valeur n’est affectée à Flow.MinuteOffsetToApply, affectez un décalage minute par défaut ; par exemple, 300. Dans cette situation, l’UTC valeur pour le temps de contrôle n’a pas une entrée supérieure ou égale à elle dans la Flow.UtcDateTimeCollection variable.
  4. Ensuite, utilisez l’expression suivante pour obtenir l’heure locale à partir de l’algorithme ci-dessus : 
    Flow.MyLocalDateTimeToUse = AddMinutes(Flow.UtcDateTimeToCheck, Flow.MinuteOffsetToApply)

Vous disposez maintenant d’une heure locale avec le biais approprié que vous pouvez utiliser pour les calculs. Le biais appliqué est basé sur la valeur de recherche dans le Flow.LocalTimezoneMinuteOffset collection.

Bien que l’approche par l’expression soit plus complexe, cette méthode ne nécessite pas de codage en dur. valeurs dans une collection avec une collection d’entiers offset correspondante. Cependant, les expressions peuvent s’avérer plus compliquées lors de l’adaptation d’un fuseau horaire particulier, en particulier si le recul ou la régression entraînent un changement de jour dans l’UTC calculs.

Dans cet exemple, le fuseau horaire avance le deuxième dimanche de mars à 7h00. UTC, et retombe le premier dimanche de novembre à 8h00, quelle que soit l'année. L’utilisation de fuseau horaire Est signifie que, pendant l’heure d’été, le décalage UTC est de -4 heures (ou -240 minutes) et qu’en dehors de l’heure d’été, le décalage UTC est de -5 heures (ou -300 minutes). Le résultat est un “local” avec le décalage approprié ajouté au UTC de -4 ou -5 heures. Pour calculer la valeur DateTime :

  1. Ajouter un Mise à jour des données action.
  2. Dans l’action Mettre à jour les données, ajoutez un mise à jour de la déclaration. 
  3. Sous Nom de variable, ajouter Flow.LocalDateTime.
  4. Sous Valeur à assigner, passez dans l’éditeur d’expressions volumineuses et ajoutez l’expression :
AddMinutes(Flow.StartDateTimeUtc,
     (
          If(Flow.StartDateTimeUtc >= GetDayOfWeekOccurrence(1,2,Year(Flow.StartDateTimeUtc),3,1,0,0)
               and Flow.StartDateTimeUtc <= GetDayOfWeekOccurrence(1,1,Year(Flow.StartDateTimeUtc),11,1,0,0),
               -240,
               -300)
     )
)

La logique de cette expression détermine si vous êtes actuellement en heure d’été, en fonction du deuxième dimanche de mars à 7 heures du matin lorsque vous avancez et du premier dimanche de novembre à 8 heures du matin lorsque vous vous repliez.

Le premier paramètre soumis à la logique Si dans l’expression ci-dessus fournit le fonctionnalité pour déterminer si un tombe dans la fenêtre DST pour le fuseau horaire Est. Utilisez-le pour déterminer si le décalage à appliquer à la devrait être soit 240 minutes (-4 heures) ou -300 minutes (-5 heures). Le reste de l’expression fournit les valeurs à appliquer. Si vous devez avoir une expression booléenne évaluée à true lorsque DST est activé ou false lorsque ce n’est pas le cas, extrayez cette logique en une expression distincte car elle renvoie une valeur booléenne :

(
      (Month(Flow.UtcDateTime) > 3)
        or
      (Month(Flow.UtcDateTime) == 3 and Month(AddDays(Flow.UtcDateTime, -7)) == 3 and Month(AddDays(Flow.UtcDateTime, -14)) == 3)
        or
      (
        (Month(Flow.UtcDateTime) == 3 and Month(AddDays(Flow.UtcDateTime, -7)) == 3 and Month(AddDays(Flow.UtcDateTime, -14)) == 2)
          and
        (DayOfWeek(Flow.UtcDateTime) > 1 or (Hour(Flow.UtcDateTime) >= 7))
      )
    )
    and
    (
      (Month(Flow.UtcDateTime) < 11)
        or
      (
        (Month(Flow.UtcDateTime) == 11 and Month(AddDays(Flow.UtcDateTime, -7)) == 10)
          and
        (
          (DayOfWeek(Flow.UtcDateTime) == 1 and Hour(Flow.UtcDateTime) < 8)
            or
          DayOfWeek(Flow.UtcDateTime)!=1
        )
      )
    )
Remarque :  Tous les types de flux peuvent utiliser le Évaluer le calendrier et Groupe Évaluer le calendrier Actions. L’utilisation d’un groupe de flux offre aux auteurs de flux possibilité de créer des calculs comme une alternative plus simple au travail avec les décalages UTC, le comportement en avant et en arrière de l’heure d’été, etc.