Lokale, feste und UTC-Varianten der aktuellen Zeitfunktionen

Wenn Sie mit Power Query in Tools wie Excel und Power BI arbeiten, ist das Behandeln von Datums- und Uhrzeitwerten genau erforderlich – insbesondere, wenn Ihre Datentransformationen von der aktuellen Uhrzeit abhängen. Power Query bietet verschiedene Funktionen zum Abrufen des aktuellen Datums und der aktuellen Uhrzeit:

• DateTime.LocalNow
• DateTimeZone.LocalNow
• DateTime.FixedLocalNow
• DateTimeZone.FixedLocalNow
• DateTimeZone.UtcNow
• DateTimeZone.FixedUtcNow.

In diesem Artikel werden die Unterschiede zwischen diesen Funktionen erläutert und erläutert, wann und warum die einzelnen Funktionen verwendet werden sollen. Darüber hinaus wird ein kritisches, aber häufig übersehenes Detail hervorgehoben. Power Query Online gibt immer UTC-Zeit zurück, auch wenn eine Funktion mit der Bezeichnung "Lokal" verwendet wird. Wenn Sie diese Nuancen verstehen, können Sie unerwartete Ergebnisse vermeiden, insbesondere beim Erstellen zeitkritischer Berichte oder beim Automatisieren von Datenupdates in Apps wie Power BI-Dienst oder Power Apps.

Unterschiede zwischen Funktionen

Jede der aktuellen Zeitfunktionen hat wichtige Unterschiede. Diese Funktionen unterscheiden sich hinsichtlich des Bewusstseins für Zeitzonen, der Volatilität (ob sich der Wert ändert, wenn er mehrmals in derselben Abfrage aufgerufen wird) und wie sie sich in verschiedenen Umgebungen (Desktop oder Online) verhalten. Die folgende Tabelle enthält eine Aufschlüsselung der einzelnen Funktionen.

In Power Query M ist die Auswahl zwischen ortszeit- und UTC-basierten Datums- und Uhrzeitfunktionen eine wichtige Entwurfsentscheidung, die sich auf die Konsistenz, Genauigkeit und Portabilität Ihrer Abfragen auswirkt. Funktionen wie DateTime.LocalNow und DateTime.FixedLocalNow sind nützlich, wenn Ihre Logik von der lokalen Systemzeit abhängt, z. B. nach Datensätzen filtern, die "heute" aufgetreten sind, oder Zeitstempel für benutzerorientierte Berichte generieren. Diese Funktionen spiegeln die Zeitzone der Umgebung wider, in der die Abfrage ausgeführt wird, wodurch sie für Power Query-Desktopszenarien geeignet sind, in denen der lokale Kontext gut definiert ist.

In verteilten oder cloudbasierten Umgebungen wie Power Query Online geben diese Funktionen jedoch UTC-Zeit zurück, nicht die tatsächliche Ortszeit des Benutzers. Diese Diskrepanz kann zu subtilen Inkonsistenzen führen, wenn ihre Logik einen lokalen Zeitkontext annimmt. Im Gegensatz dazu bieten DateTimeZone.UtcNow und DateTimeZone.FixedUtcNow einen zeitzonenneutralen Referenzpunkt, der in allen Umgebungen konsistent ist und weder von Sommerzeit noch von regionalen Einstellungen beeinflusst wird. Diese UTC-basierten Funktionen sind die bevorzugte Wahl für Szenarien mit Datenintegration, Protokollierung, Überwachung oder jeder Logik, die sich unabhängig davon, wo oder wann die Abfrage ausgeführt wird, identisch verhalten muss.

Unterschiede zwischen den Funktionen LocalNow und FixedLocalNow

Power Query M bietet vier Funktionen zum Abrufen der aktuellen Ortszeit:

• DateTime.LocalNow gibt jedes Mal, wenn der Ausdruck ausgewertet wird, den aktuellen Ort datetime zurück.
• DateTime.FixedLocalNow gibt die lokale datetime einmal pro Abfrageauswertung zurück, die als Momentaufnahme fungiert.
• DateTimeZone.LocalNow gibt jedes Mal, wenn der Ausdruck ausgewertet wird, den aktuellen Ort datetimezone zurück.
• DateTimeZone.FixedLocalNow gibt die lokale datetimezone einmal pro Abfrageauswertung zurück, die als Momentaufnahme fungiert.

Um den Unterschied zu veranschaulichen, generiert das folgende Beispiel eine Tabelle mit mehreren Zeilen. Jede Zeile erfasst einen neuen DateTime.LocalNow Wert mithilfe einer Verzögerung, um unterschiedliche Zeitstempel sicherzustellen, während jeder erfasste DateTime.FixedLocalNow Wert über alle Zeilen konstant bleibt.

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

Das Ergebnis dieses Beispiels ist:

Wenn Sie sich die Ausgabe ansehen, stellen Sie möglicherweise fest, dass, auch wenn die DateTime.LocalNow-Funktion zuerst im Code erscheint, der für DateTime.FixedLocalNow zurückgegebene Wert eine Zeit zeigt, die vor der DateTime.LocalTime-Zeit liegt. Obwohl DateTime.LocalNow in der Tabellenerstellung zuerst aufgeführt ist, wird in Power Query M die Reihenfolge der Auswertung nicht garantiert so vorgenommen, dass sie der Reihenfolge der Felder in einer Tabelle entspricht. Stattdessen verwendet Power Query ein faules Auswertungsmodell. Die Verwendung dieses Modells bedeutet, dass Felder nur bei Bedarf ausgewertet werden und das Modul die Auswertungsreihenfolge bestimmt, nicht die Reihenfolge im Code. In diesem Fall wird die DateTime.FixedLocalNow-Funktion zuerst ausgewertet, sodass die erste Rückgabezeit für diese Funktion vor der ersten Rückgabezeit für DateTime.LocalNow erfolgt.

Das folgende Beispiel zeigt, wie ähnliche Ergebnisse mittels DateTimeZone.LocalNow und DateTimeZone.FixedLocalNow erzeugt werden können.

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

Die Ausgabe dieses Beispiels in Power Query Desktop lautet:

Unterschiede zwischen den Funktionen UtcNow und FixedUtcNow

Power Query M bietet zwei Funktionen zum Abrufen der aktuellen UTC-Zeit:

• DateTimeZone.UtcNow gibt die aktuelle UTC datetimezone jedes Mal zurück, wenn der Ausdruck ausgewertet wird.
• DateTimeZone.FixedUtcNow gibt die lokale datetimezone einmal pro Abfrageauswertung zurück, die als Momentaufnahme fungiert.

Die Unterschiede zwischen diesen beiden Funktionen ähneln den Funktionen LocalNow und FixedLocalNow. Unabhängig davon, ob die Funktionen in Power Query Desktop oder Power Query Online ausgeführt werden, werden die Rückgabewerte immer als UTC-Zeit zurückgegeben. Im folgenden Beispiel werden die Unterschiede zwischen diesen beiden Funktionen veranschaulicht.

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

Die Ausgabe dieses Beispiels in Power Query Desktop und Power Query Online lautet:

Auswirkungen auf andere Funktionen

Andere Power Query M-Funktionen, die vom aktuellen Datum und der aktuellen Uhrzeit abhängen, können auch davon beeinflusst werden, wie die lokale Uhrzeit auf Power Query Desktop oder Power Query Online zurückgegeben wird. Wenn Sie z. B. die DateTimeZone.ToLocal Funktion verwenden, um UTC-Zeit in lokale Zeit zu konvertieren, gibt sie weiterhin die UTC-Zeit in Power Query Online zurück.

Ein weiteres Beispiel ist eine beliebige Funktion, die die aktuelle Systemzeit als Parameter verwenden kann. Diese Funktionen umfassen Date.Month, Date.DayOfYearDateTime.IsInCurrentYear, DateTimeZone.ZoneHoursoder eine beliebige andere Funktion, die das aktuelle Datum und die aktuelle Uhrzeit auswerten kann.

Wenn Ihre Logik in all diesen Funktionen davon abhängt, ob ein Wert innerhalb des aktuellen Tages, der Stunde, des Monats oder des Jahres liegt, können sich die Ergebnisse zwischen Umgebungen unterscheiden. Diese Unterschiede zwischen Umgebungen sind besonders spürbar, wenn die Abfrage nahe einer Grenze ausgeführt wird (z. B. unmittelbar vor oder nach Mitternacht, Beginn eines neuen Monats oder eines neuen Jahres). Wenn die Konsistenz in verschiedenen Umgebungen von entscheidender Bedeutung ist, verwenden Sie die DateTimeZone.UtcNow Funktionen, DateTimeZone.FixedUtcNow um das Datum und die Uhrzeit abzurufen.

Bewährte Methoden und Empfehlungen

Die Auswahl der richtigen Zeitfunktion in Power Query hängt von Ihrem spezifischen Anwendungsfall, der Umgebung ab, in der Ihre Abfrage ausgeführt wird (Desktop oder Online), und ob Sie einen dynamischen oder festen Zeitstempel benötigen. Im Folgenden finden Sie einige bewährte Methoden, die Sie bei der Entscheidung unterstützen:

• Seien Sie explizit zu Zeitzonen: Verwenden Sie die DateTimeZone-Funktionen anstelle von DateTime-Funktionen, wenn der Zeitzonenkontext wichtig ist. Verwenden Sie DateTimeZone.UtcNow oder DateTimeZone.FixedUtcNow für Konsistenz in allen Umgebungen, insbesondere in cloudbasierten Lösungen wie dem Power BI-Dienst.
• Verwenden Sie feste Funktionen für wiederholbare Ergebnisse: Verwenden Sie die festen Varianten (z.DateTimeZone.FixedUtcNow B.), wenn der Zeitstempel bei Auswertungen über mehrere Abfragen hinweg konstant bleiben soll. Diese Methode eignet sich besonders für die Protokollierung, Überwachung oder Erfassung der Datenaufnahmezeit.
• Vermeiden Sie lokale Funktionen in Power Query Online: Funktionen wie DateTime.LocalNow und DateTimeZone.LocalNow geben UTC-Zeit in cloudbasierten Lösungen wie Power BI-Dienst zurück, was zu Verwirrung oder falschen Annahmen führen kann. Wenn Sie eine tatsächliche Ortszeit im Dienst benötigen, sollten Sie die UTC manuell mithilfe bekannter Offsets anpassen (obwohl diese Anpassung brüchig sein kann, z. B. aufgrund von Sommerzeit oder regionalen Einstellungen).
• Test in Desktop- und Onlineumgebungen: Testen Sie Ihre Abfragen immer sowohl in Power Query Desktop als auch in Power Query Online, wenn Ihre Logik von der aktuellen Zeit abhängt. Diese Tests helfen, Diskrepanzen frühzeitig abzufangen, insbesondere bei geplanten Aktualisierungsszenarien.
• Dokumentieren Sie Ihre Zeitlogik: Kommentieren Oder dokumentieren Sie klar, warum eine bestimmte Zeitfunktion verwendet wird, insbesondere, wenn Sie eine Problemumgehung für die Behandlung von Zeitzonen verwenden. Diese Informationen helfen zukünftigen Mitarbeitern, die Absicht hinter der Logik zu verstehen.
• Verwenden Sie UTC für geplante Workflows: Für geplante Aktualisierungen oder automatisierte Pipelines ist UTC die sicherste und vorhersehbarste Wahl. Es vermeidet Mehrdeutigkeiten, die durch Sommerzeit oder regionale Zeitzonenverschiebungen verursacht werden.
• Cachezeitwerte bei Bedarf: Wenn Sie den gleichen Zeitstempel in mehreren Schritten in einer Abfrage verwenden müssen, weisen Sie sie einer Variablen am anfang der Abfrage mithilfe einer festen Funktion zu. Diese Variable stellt die Konsistenz in der gesamten Transformationslogik sicher.