Partager via

Variantes locales, fixes et UTC des fonctions d’heure actuelle

Lorsque vous travaillez avec Power Query dans des outils tels qu’Excel et Power BI, la gestion des valeurs de date et d’heure est essentielle, en particulier lorsque vos transformations de données dépendent de l’heure actuelle. Power Query offre différentes fonctions pour récupérer la date et l’heure actuelles :

Cet article explore les distinctions entre ces fonctions et précise quand et pourquoi utiliser chacun d’eux. En outre, il met en évidence un détail critique mais souvent négligé. Power Query Online retourne toujours l’heure UTC même lorsque vous utilisez une fonction intitulée « Local ». Comprendre ces nuances peut vous aider à éviter des résultats inattendus, en particulier lors de la création de rapports sensibles au temps ou de l’automatisation des mises à jour des données dans des applications telles que le service Power BI ou Power Apps.

Différences entre les fonctions

Chacune des fonctions temporelles actuelles présente des différences importantes. Ces fonctions varient en termes de prise en charge des fuseaux horaires, de volatilité (si la valeur change lorsqu’elle est appelée plusieurs fois dans la même requête) et de la façon dont elles se comportent dans différents environnements (bureau et en ligne). Le tableau suivant contient une répartition de chaque fonction.

Fonction Retours Volatilité Comportement du bureau Comportement en ligne Cas d’utilisation classique
DateTime.LocalNow Une datetime représentant l’heure locale actuelle Dynamique : retourne une nouvelle valeur chaque fois qu’elle est appelée pendant l’évaluation de la requête Retourne l’heure de l’ordinateur local Retourne l’heure UTC Horodatage local rapide sans contexte de fuseau horaire
DateTimeZone.LocalNow Valeur datetimezone représentant l’heure locale actuelle avec décalage de fuseau horaire Dynamique : retourne une nouvelle valeur chaque fois qu’elle est appelée pendant l’évaluation de la requête Retourne l'heure locale avec décalage horaire Retourne l’heure UTC avec le décalage de +00:00 Heure locale avec prise en charge du fuseau horaire
DateTime.FixedLocalNow Valeur datetime représentant l’heure locale lors du premier appel pendant l’évaluation de la requête Fixe—retourne la même valeur tout au long d’une évaluation de requête unique Capture l’heure locale lors du premier appel Capture l'heure UTC lors du premier appel Instantané de l’heure locale sans fuseau horaire
DateTimeZone.FixedLocalNow Valeur datetimezone représentant l'heure locale avec décalage lors du premier appel pendant l'évaluation de la requête. Fixe—retourne la même valeur tout au long d’une évaluation de requête unique Capture l’heure locale avec décalage lors du premier appel Captures le temps UTC avec un décalage de +00:00 lors du premier appel. Instantané de l’heure locale avec fuseau horaire
DateTimeZone.UtcNow Valeur datetimezone représentant l’heure UTC actuelle Dynamique : retourne une nouvelle valeur chaque fois qu’elle est appelée pendant l’évaluation de la requête Retourne l’heure UTC actuelle Retourne l’heure UTC actuelle Horodatage UTC cohérent pour les scénarios dynamiques
DateTimeZone.FixedUtcNow Valeur datetimezone représentant l’heure UTC lors du premier appel dans le cadre de l’évaluation de la requête Fixe—retourne la même valeur tout au long d’une évaluation de requête unique Capture l'heure UTC lors du premier appel Capture l'heure UTC lors du premier appel Horodatage UTC corrigé pour la journalisation ou l’audit

Dans Power Query M, le choix entre l’heure locale et les fonctions de date et d’heure UTC est une décision de conception critique qui affecte la cohérence, la précision et la portabilité de vos requêtes. Les fonctions comme DateTime.LocalNow et DateTime.FixedLocalNow sont utiles lorsque votre logique dépend de l’heure système locale, comme le filtrage des enregistrements qui se sont produits « aujourd’hui » ou la génération d’horodatages pour les rapports accessibles par l’utilisateur. Ces fonctions reflètent le fuseau horaire de l’environnement dans lequel la requête est exécutée, ce qui les rend adaptées aux scénarios Power Query Desktop où le contexte local est bien défini.

Toutefois, dans des environnements distribués ou cloud comme Power Query Online, ces mêmes fonctions retournent l’heure UTC, et non l’heure locale réelle de l’utilisateur. Cette différence peut entraîner des incohérences subtiles si votre logique suppose un contexte de temps local. En revanche, DateTimeZone.UtcNow et DateTimeZone.FixedUtcNow fournissent un point de référence neutre de fuseau horaire qui est cohérent entre les environnements et non affecté par les paramètres régionaux et d’heure d’été. Ces fonctions UTC sont le choix préféré pour les scénarios impliquant l’intégration de données, la journalisation, l’audit ou toute logique qui doit se comporter de façon identique, quel que soit l’emplacement ou l’exécution de la requête.

Différences entre les fonctions LocalNow et FixedLocalNow

Power Query M fournit quatre fonctions pour récupérer l’heure locale actuelle :

  • DateTime.LocalNow retourne le local datetime actuel chaque fois que l’expression est évaluée.
  • DateTime.FixedLocalNow renvoie la valeur locale datetime une fois par évaluation de requête, comme un instantané.
  • DateTimeZone.LocalNow retourne le local datetimezone actuel chaque fois que l’expression est évaluée.
  • DateTimeZone.FixedLocalNow retourne la valeur datetimezone locale une fois par évaluation de requête, agissant en tant qu’image instantanée

Pour illustrer la différence, l’exemple suivant génère une table avec plusieurs lignes. Chaque ligne capture une DateTime.LocalNow nouvelle valeur à l’aide d’un délai pour garantir des horodatages distincts, tandis que chaque valeur capturée DateTime.FixedLocalNow reste constante sur toutes les lignes.

Remarque

Toutes les dates et heures de la sortie des exemples de cet article dépendent de l’exécution des fonctions. Les dates et heures affichées dans la sortie sont uniquement à des fins de démonstration.

let
    // Create a table with LocalNow and FixedLocalNow columns 
    TableWithTimes = Table.FromList(
        {1..5},
        each {
            _,
            Function.InvokeAfter(() => DateTime.LocalNow(), #duration(0, 0, 0, 0.2)),
            Function.InvokeAfter(() => DateTime.FixedLocalNow(), #duration(0, 0, 0, 0.2))
        },
        {"Index", "LocalNow", "FixedLocalNow"}
    ),

    // Format both datetime columns
    FormatLocalNow = Table.TransformColumns(TableWithTimes, 
        {{"LocalNow", each DateTime.ToText(_, "yyyy-MM-ddThh:mm:ss.fff")}}),
    FormatFixedNow = Table.TransformColumns(FormatLocalNow, 
        {{"FixedLocalNow", each DateTime.ToText(_, "yyyy-MM-ddThh:mm:ss.fff")}}),

    // Change the table types
    FinalTable =  Table.TransformColumnTypes(FormatFixedNow, {{"Index", Int64.Type}, 
        {"LocalNow", type text}, {"FixedLocalNow", type text}})

in
    FinalTable

La sortie de cet exemple est :

Capture d’écran de la table créée avec DateTime.LocalNow des dates et des heures dynamiques et DateTime.FixedLocalNow avec des dates et des heures fixes.

Si vous examinez la sortie, vous remarquerez peut-être que même si DateTime.LocalNow la fonction apparaît en premier dans le code, la valeur retournée pour DateTime.FixedLocalNow affiche une heure qui se produit avant l'heure de DateTime.LocalTime. Même si DateTime.LocalNow est répertorié en premier dans la construction de la table, l'ordre d'évaluation dans Power Query M n'est pas garanti de suivre l'ordre des champs d'une table. Au lieu de cela, Power Query utilise un modèle d’évaluation différé. L’utilisation de ce modèle signifie que les champs sont évalués uniquement si nécessaire et que le moteur détermine l’ordre d’évaluation, et non l’ordre dans votre code. Dans ce cas, la DateTime.FixedLocalNow fonction est évaluée en premier, de sorte que la première fois retournée pour cette fonction se produit avant la première fois retournée pour DateTime.LocalNow.

L’exemple suivant montre comment produire des résultats similaires à l’aide DateTimeZone.LocalNow et DateTimeZone.FixedLocalNow.

let
    // Create a table with LocalNow and FixedLocalNow columns 
    TableWithTimes = Table.FromList(
        {1..5},
        each {
            _,
            Function.InvokeAfter(() => DateTimeZone.LocalNow(), #duration(0, 0, 0, 0.2)),
            Function.InvokeAfter(() => DateTimeZone.FixedLocalNow(), #duration(0, 0, 0, 0.2))
        },
        {"Index", "LocalNow", "FixedLocalNow"}
    ),

    // Format both datetimezone columns
    FormatLocalNow = Table.TransformColumns(TableWithTimes, 
        {{"LocalNow", each DateTimeZone.ToText(_, "yyyy-MM-ddThh:mm:ss.fff:zzz")}}),
    FormatFixedNow = Table.TransformColumns(FormatLocalNow, 
        {{"FixedLocalNow", each DateTimeZone.ToText(_, "yyyy-MM-ddThh:mm:ss.fff:zzz")}}),

    //  Change the table types
    FinalTable =  Table.TransformColumnTypes(FormatFixedNow, 
        {{"Index", Int64.Type}, {"LocalNow", type text}, {"FixedLocalNow", type text}})
in
    FinalTable

La sortie de cet exemple dans Power Query Desktop est la suivante :

Capture d’écran de la table créée avec DateTimeZone.LocalNow des dates et des heures dynamiques et DateTimeZone.FixedLocalNow avec des dates et des heures fixes.

Remarque

Si vous exécutez cet exemple dans Power Query Online, l’heure retournée est toujours l’heure UTC et la partie fuseau horaire des valeurs retournées est toujours +00:00.

Différences entre les fonctions UtcNow et FixedUtcNow

Power Query M fournit deux fonctions pour récupérer l’heure UTC actuelle :

  • DateTimeZone.UtcNow retourne l’utc datetimezone actuel chaque fois que l’expression est évaluée.
  • DateTimeZone.FixedUtcNow renvoie la valeur locale datetimezone une fois par évaluation de requête, comme un instantané.

Les différences entre ces deux fonctions sont similaires aux fonctions LocalNow et FixedLocalNow. Toutefois, si les fonctions sont exécutées dans Power Query Desktop ou Power Query Online, les valeurs de retour sont toujours retournées en tant qu’heure UTC. L’exemple suivant illustre les différences entre ces deux fonctions.

let
    // Create a table with UtcNow and FixedUtcNow columns 
    TableWithTimes = Table.FromList(
        {1..5},
        each {
            _,
            Function.InvokeAfter(() => DateTimeZone.UtcNow(), #duration(0, 0, 0, 0.2)),
            Function.InvokeAfter(() => DateTimeZone.FixedUtcNow(), #duration(0, 0, 0, 0.2))
        },
        {"Index", "UtcNow", "FixedUtcNow"}
    ),

    // Format both datetimezone columns
    FormatLocalNow = Table.TransformColumns(TableWithTimes, 
        {{"UtcNow", each DateTimeZone.ToText(_, "yyyy-MM-ddThh:mm:ss.fff:zzz")}}),
    FormatFixedNow = Table.TransformColumns(FormatLocalNow, 
        {{"FixedUtcNow", each DateTimeZone.ToText(_, "yyyy-MM-ddThh:mm:ss.fff:zzz")}}),

    //  Change the table types
    FinalTable =  Table.TransformColumnTypes(FormatFixedNow, 
        {{"Index", Int64.Type}, {"UtcNow", type text}, {"FixedUtcNow", type text}})
in
    FinalTable

La sortie de cet exemple dans Power Query Desktop et Power Query Online est la suivante :

Capture d’écran de la table créée avec DateTimeZone.UtcNow des dates et des heures dynamiques et DateTimeZone.FixedUtcNow avec des dates et des heures fixes.

Effets sur d’autres fonctions

D’autres fonctions Power Query M qui dépendent de la date et de l’heure actuelles peuvent également être affectées par la façon dont l’heure locale est retournée sur Power Query Desktop ou Power Query Online. Par exemple, si vous utilisez la fonction pour convertir l’heure DateTimeZone.ToLocal UTC en heure locale, elle retourne toujours l’heure UTC sur Power Query Online.

Un autre exemple est n’importe quelle fonction qui peut utiliser l’heure système actuelle en tant que paramètre. Ces fonctions incluent Date.Month, , Date.DayOfYearDateTime.IsInCurrentYear, DateTimeZone.ZoneHoursou toute autre fonction qui peut évaluer la date et l’heure actuelles.

Dans toutes ces fonctions, si votre logique dépend si une valeur se situe dans le jour, l’heure, le mois ou l’année en cours, les résultats peuvent différer entre les environnements. Ces différences entre les environnements sont particulièrement notables si la requête s’exécute près d’une limite (par exemple, juste avant ou après minuit, début d’un nouveau mois ou nouvelle année). Si la cohérence est cruciale dans différents environnements, utilisez les fonctions DateTimeZone.UtcNow ou DateTimeZone.FixedUtcNow pour récupérer la date et l’heure.

Meilleures pratiques et recommandations

Le choix de la fonction de temps appropriée dans Power Query dépend de votre cas d’usage spécifique, de l’environnement dans lequel votre requête s’exécute (bureau ou en ligne) et de la nécessité d’un horodatage dynamique ou fixe. Voici quelques bonnes pratiques pour vous aider à guider votre décision :

  • Soyez explicite sur les fuseaux horaires : utilisez les fonctions DateTimeZone au lieu des fonctions DateTime lorsque le contexte du fuseau horaire importe. Utilisez DateTimeZone.UtcNow ou DateTimeZone.FixedUtcNow pour assurer la cohérence entre les environnements, en particulier dans les solutions cloud telles que le service Power BI.
  • Utilisez des fonctions fixes pour les résultats reproductibles : utilisez les variantes fixes (par exemple DateTimeZone.FixedUtcNow) lorsque vous souhaitez que l’horodatage reste constant entre les évaluations des requêtes. Cette méthode est particulièrement utile pour la journalisation, l’audit ou la capture du temps d’ingestion des données.
  • Évitez les fonctions locales dans Power Query Online : les fonctions comme DateTime.LocalNow et DateTimeZone.LocalNow retournent l’heure UTC dans des solutions cloud telles que le service Power BI, ce qui peut entraîner des confusions ou des hypothèses incorrectes. Si vous avez besoin de l’heure locale réelle dans le service, envisagez d’ajuster l’heure UTC manuellement à l’aide de décalages connus (bien que cet ajustement puisse être fragile, par exemple, en raison de l’heure d’été ou des paramètres régionaux).
  • Test dans les environnements de bureau et en ligne : testez toujours vos requêtes dans Power Query Desktop et Power Query Online si votre logique dépend de l’heure actuelle. Ce test permet d’intercepter les écarts précoces, en particulier pour les scénarios d’actualisation planifiée.
  • Documentez votre logique de temps : commentez ou documentez clairement pourquoi une fonction de temps spécifique est utilisée, en particulier si vous utilisez une solution de contournement pour la gestion des fuseaux horaires. Ces informations aident les collaborateurs futurs à comprendre l’intention derrière la logique.
  • Utilisez UTC pour les flux de travail planifiés : pour les actualisations planifiées ou les pipelines automatisés, UTC est le choix le plus sûr et le plus prévisible. Il évite l’ambiguïté causée par le temps d’été ou les décalages de fuseau horaire régional.
  • Valeurs de temps de cache si nécessaire : si vous devez utiliser le même horodatage sur plusieurs étapes d’une requête, affectez-la à une variable en haut de votre requête à l’aide d’une fonction fixe. Cette variable garantit la cohérence tout au long de la logique de transformation.
  • Last updated on