Ik zie in de Bridge Online nog parameterwaarden qua filters die ik niet verwacht.
De waarden zijn:
w1 = 31-12-2021 23:00:00 (datetime), w2 = 31-12-2024 23:00:00 (datetime)
terwijl ik in Power BI filter met :
01-01-2022 00:00:00, 01-01-2025 00:00:00
Ik vermoed dat de tijdzone van Nederland (+1) wordt toegevoegd, maar ik zou verwachten dat dit geen invloed zou moeten hebben. Hoe zit dit precies?
Power BI genereert een OData-verzoek.
Dit kan ook handmatig samengesteld worden zoals:
https://bridge-online.cloud/invantive-autotask/odata4/Autotask.Tickets.Tickets@at?$filter=lastActivityDate%20gt%202021-02-03T04:05:06Z
Hier zit een filter op het veld lastActivityDate op met de tijdsrepresentatie “Z” met “Z” is “Zulu Time” oftewel UTC-tijd.
Deze URL zal in Invantive Bridge Online Monitoring leiden tot de verwachte tijden in UTC:
w1 = 03-02-2021 04:05:06 (datetime)
zoals zichtbaar in onderstaande afbeelding:
Dit is het gewenste en verwachte gedrag.
De onderstaande Power Query:
let
Bron = OData.Feed("https://bridge-online.cloud/invantive-autotask/odata4", null, [Implementation="2.0", ODataVersion=4, OmitValues=ODataOmitValues.Nulls, Headers=[Referer = "sample-timezone" ], Timeout=#duration(0,1,0,0)]),
#"Autotask.Tickets.Tickets@at_table" = Bron{[Name="Autotask.Tickets.Tickets@at",Signature="table"]}[Data],
#"Rijen gefilterd" = Table.SelectRows(#"Autotask.Tickets.Tickets@at_table", each [lastActivityDate] > #datetimezone(2021, 2, 3, 4, 5, 6, 0, 0))
in
#"Rijen gefilterd"
zal leiden tot deze OData URL:
https://bridge-online.cloud/invantive-autotask/odata4/Autotask.Tickets.Tickets@at?$filter=lastActivityDate%20gt%202021-02-03T04%3A05%3A06Z
In de Power BI-editor ziet dat er uit als:
Indien een Power BI-gebruiker via de user interface een datumfilter opgeeft zoals:
dan voegt dat een filterstap toe in Power Query. Bij het opnieuw opvragen van dit filter is er iets verandert zonder dat de gebruiker daar expliciet om gevraagd heeft:
Een tijdzone +01:00 is toegevoegd.
In Invantive Bridge Online Monitoring leidt dit tot het gedrag uit de vraag:
op basis van de door Power BI-gegenereerde URL:
https://bridge-online.cloud/invantive-autotask/odata4/Autotask.Tickets.Tickets@at?$filter=lastActivityDate%20gt%202021-02-03T00%3A00%3A00%2B01%3A00&$top=1000
In Power Query is die compensatie ook terug te vinden bij #datetimezone:
let
Bron = OData.Feed("https://bridge-online.cloud/invantive-autotask/odata4", null, [Implementation="2.0", ODataVersion=4, OmitValues=ODataOmitValues.Nulls, Headers=[Referer = "sample-timezone" ], Timeout=#duration(0,1,0,0)]),
#"Autotask.Tickets.Tickets@at_table" = Bron{[Name="Autotask.Tickets.Tickets@at",Signature="table"]}[Data],
#"Rijen gefilterd" = Table.SelectRows(#"Autotask.Tickets.Tickets@at_table", each [lastActivityDate] > #datetimezone(2021, 2, 3, 0, 0, 0, 1, 0))
in
#"Rijen gefilterd"
Zoals gedocumenteerd op #datetimezone - PowerQuery M | Microsoft Learn is de eennalaatste parameter het aantal uren verschuiving voor de tijdzone en de laatste parameter het aantal minuten (voor bijvoorbeeld India met 04:30 verschuiving).
De omgang met datum/tijdvelden is hiermee nog niet volledig beschreven.
Ook applicaties kunnen een referentietijdzone hanteren, die vaak slecht of niet gedocumenteerd is. In algemene zin kan gesteld worden dat dit meestal de tijd is van de regio waar de applicatie veel gebruikt wordt. Exact Online Nederland zal bijvoorbeeld vaak CET als uitgangspunt hebben terwijl internationaal georienteerde applicaties vaak UTC als referentie gebruiken.
Om nog complexer te maken kennen we ook nog zomertijd en wintertijd, die niet alleen per regio verschillen, maar waarbij gebieden ook vaak gewisseld hebben tussen systematiek in de loop van jaren en eeuwen. Als startpunt in deze complexe materia kan Time Zone Database gebruikt worden. De complexiteit is groot; datum/tijdregistratie is een onderwerp dat vele malen complexer is dan bijvoorbeeld character sets en qua complexiteit eerder lijkt op coordinatensystemen zoals WGS84 en RD. Binnen RD spelen bijvoorbeeld ook tijdsgebondenregistraties zoals het correctiegrid maar ook het kleiner of groter worden van afstanden door geologische bewegingen in de loop der eeuwen.
Er zijn applicaties die werken met een vaste referentie qua zomer-/winter-tijd en tijdzone, maar er zijn ook applicatie die tijden vastleggen in de toen geldende zomer/wintertijd. Daarnaast kunnen er grote verschillen zijn binnen applicaties, bijvoorbeeld per administratie, bedrijf of legacy database.
SQL-drivers binnen Invantive UniversalSQL houden geen rekening met applicatiespecifieke afhandeling hiervan. De universele aanname (of eigenlijk preconditie) is dat de aannames is dat alle gegevens in UTC-tijdzone zijn vastgelegd. Dit is met zekerheid vaak niet kloppend, maar maakt het probleem eenvoudiger om op te lossen.
Door deze keuze is niet alleen de semantiek duidelijk, maar kunnen ook database-indexen en/of tabelfunctieparameters (zoals op Teamleader Focus) effectief ingezet worden, zodat de prestaties beter zijn.
Voor de ontwikkelaar van rapportages is het advies om zelf vast te stellen hoe de desbetreffende applicatie-omgeving omgaat met datum- en tijdnotatie, en eventuele verschillen in zomer-/wintertijd in de loop van de jaren.
In het algemeen is het advies om ook binnen Power BI qua filters te werken met UTC-tijden, en niet zoals boven bij “Power BI Handmatig” getoond te vertrouwen dat Power BI zelf hierin logische keuzes maakt.
Deze vraag is automatisch gesloten na 1 week inactiviteit. Het laatste gegeven antwoord is gemarkeerd als oplossing.
Gelieve een nieuwe vraag te stellen via een apart topic als het probleem opnieuw optreedt. Gelieve in de nieuwe vraag een link naar dit topic op te nemen door de URL er van in de tekst te plakken.
Dit topic is 3 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.