Rozjazdy danych po zmianie strefy czasowej w Power BI 🕒 Jak naprawić

Dlaczego zmiana strefy czasowej potrafi rozjechać wyniki w Power BI względem źródła?

Bo ta sama wartość daty i czasu może być interpretowana inaczej w źródle danych, w Power Query, w modelu Power BI i podczas odświeżania w usłudze. Jeśli źródło zapisuje czas lokalny, a Power BI odczyta go jako UTC albo odwrotnie, to moment zdarzenia przesuwa się o kilka godzin. W efekcie część rekordów może trafić do innego dnia, miesiąca, zakresu raportowego lub okna filtra niż w systemie źródłowym.

Najczęstszy problem wynika z tego, że pole daty wygląda identycznie, ale nie niesie tej samej informacji semantycznej. DataTime bez strefy to tylko lokalna data i godzina, natomiast DateTimeZone zawiera również informację o przesunięciu względem UTC. Gdy dane są konwertowane między tymi typami albo odświeżane w środowisku działającym w innej strefie czasowej, Power BI może przeliczyć moment na inny czas niż źródło. To szczególnie często daje różnice w raportach dziennych, przy agregacji po dacie oraz w filtrach typu „dzisiaj”, „wczoraj” lub „ostatnie 24 godziny”.

Rozjazdy pojawiają się też przy zmianie czasu letniego i zimowego. Wtedy część godzin występuje dwa razy albo nie występuje wcale, więc bez jednoznacznego zapisu strefy dwa systemy mogą inaczej przypisać rekord do osi czasu. Z perspektywy użytkownika wygląda to jak błąd sum lub liczności, ale faktycznie problem dotyczy momentu, do którego przypisano zdarzenie.

Kluczowe jest zrozumienie, że Power BI nie zawsze „pokazuje inne dane” — często pokazuje te same rekordy po innym przeliczeniu czasu. Jeśli źródło, transformacje i model nie używają jednej spójnej zasady przechowywania i interpretacji czasu, wyniki względem źródła mogą się rozjechać mimo poprawnego działania samego raportu.

💡 Protip: Jeśli porównujesz Power BI ze źródłem, najpierw ustal, czy oba systemy interpretują timestamp jako lokalny czas czy UTC — identyczny zapis daty nie oznacza jeszcze tego samego momentu. Najmniej błędów daje jedna zasada end-to-end: przechowuj czas w UTC, a lokalizację stosuj dopiero na etapie prezentacji.

Czy dane powinny być trzymane w UTC, a konwersja robiona dopiero w raporcie?

W większości przypadków tak: najbezpieczniejszym punktem odniesienia do przechowywania dat i czasu jest UTC, a prezentację w lokalnej strefie warto robić dopiero na etapie raportu lub warstwy semantycznej. Dzięki temu źródło danych pozostaje jednoznaczne, niezależne od lokalizacji użytkownika, zmian czasu letniego i ustawień serwera, bramy czy usługi odświeżania.

To podejście jest szczególnie ważne wtedy, gdy analizujesz zdarzenia z wielu krajów, łączysz dane z różnych systemów albo porównujesz wartości w czasie. Jeśli zapiszesz moment zdarzenia w czasie lokalnym bez jednoznacznego odniesienia do strefy, ten sam znacznik może być interpretowany różnie. UTC eliminuje tę niejednoznaczność, bo zapisuje jeden rzeczywisty moment na osi czasu.

Konwersja na czas lokalny w raporcie ma sens wtedy, gdy służy głównie do prezentacji dla odbiorcy. Użytkownik widzi godzinę zgodną z jego kontekstem biznesowym, ale logika danych opiera się nadal na wspólnej bazie czasowej. Trzeba jednak pamiętać, że sama konwersja nie może być przypadkowym dodaniem stałej liczby godzin. Jeśli raport ma poprawnie działać na granicach zmiany czasu letniego i zimowego, musi uwzględniać reguły konkretnej strefy czasowej, a nie tylko prosty offset.

Są też sytuacje, w których oprócz UTC warto przechowywać oryginalną strefę lub lokalny czas biznesowy. Dotyczy to na przykład procesów rozliczanych według lokalnej daty dnia roboczego, godzin otwarcia punktu lub przepisów obowiązujących w danym kraju. W takim przypadku UTC nadal powinno być technicznym źródłem prawdy dla momentu zdarzenia, ale dodatkowy atrybut strefy albo lokalnej daty może być potrzebny do poprawnych analiz biznesowych.

Praktyczna zasada jest więc prosta: moment zdarzenia przechowuj w UTC, a lokalną interpretację pokazuj lub wyliczaj świadomie tam, gdzie jest potrzebna. To minimalizuje ryzyko rozjazdów danych w Power BI i ułatwia utrzymanie spójności między źródłem, odświeżaniem i raportem.

Gdzie bezpieczniej konwertować czas: w Power Query czy w DAX i dlaczego?

Bezpieczniej konwertować czas w Power Query, ponieważ jest to etap przygotowania danych przed ich załadowaniem do modelu. Dzięki temu każda wartość daty i czasu zostaje przeliczona raz, według jasno zdefiniowanej reguły, a do modelu trafia już spójny wynik. To ogranicza ryzyko, że różne wizualizacje, miary lub obliczenia będą interpretowały ten sam znacznik czasu w odmienny sposób.

DAX jest lepszy do analizy na danych już załadowanych, ale nie jest idealnym miejscem do podstawowej normalizacji stref czasowych. Obliczenia w DAX działają w kontekście modelu i raportu, więc łatwiej tam o niespójności między kolumnami obliczanymi, miarami i filtrowaniem czasu. Jeśli konwersja strefy jest wykonywana dopiero w DAX, część logiki biznesowej może opierać się na czasie źródłowym, a część na czasie już przeliczonym, co prowadzi do rozjazdów w agregacjach, relacjach z kalendarzem i analizie po dniach lub godzinach.

Power Query daje też większą kontrolę nad technicznym typem danych, kolejnością transformacji i ujednoliceniem źródeł. To szczególnie ważne wtedy, gdy dane pochodzą z różnych systemów i nie wszystkie zapisują strefę czasową w ten sam sposób. W praktyce oznacza to, że konwersję czasu warto wykonać jak najwcześniej, najlepiej w Power Query, a w DAX zostawić jedynie logikę analityczną opartą na już ustandaryzowanym czasie.

Wyjątek ma sens tylko wtedy, gdy potrzebujesz świadomie prezentować różne warianty czasu w zależności od kontekstu raportu, ale nawet wtedy bazowy czas referencyjny powinien być najpierw uporządkowany w Power Query. To podejście jest po prostu bardziej przewidywalne, łatwiejsze do audytu i bezpieczniejsze dla spójności danych.

Jak poradzić sobie z przejściem czasu letniego/zimowego (DST) bez podwójnych godzin?

Najbezpieczniejsza zasada jest prosta: przechowuj i łącz dane po czasie UTC, a czas lokalny traktuj wyłącznie jako warstwę prezentacji. Problem DST polega na tym, że przy przejściu z czasu letniego na zimowy ta sama lokalna godzina występuje dwa razy, a przy przejściu z zimowego na letni jedna godzina lokalna nie istnieje. Jeśli model lub raport opiera się wyłącznie na lokalnym znaczniku czasu, to ta sama wartość, np. 2024-10-27 02:30, może oznaczać dwa różne momenty rzeczywiste.

Aby uniknąć „podwójnych godzin”, każdemu zdarzeniu trzeba przypisać jednoznaczny punkt w czasie, czyli timestamp w UTC, a jeśli potrzebny jest widok lokalny, wyliczać go na podstawie reguł strefy czasowej i daty zdarzenia. Dzięki temu agregacje, sortowanie, relacje i deduplikacja działają poprawnie, bo bazują na czasie ciągłym, bez powtórzeń i luk wynikających z DST.

W praktyce oznacza to, że w Power BI nie należy używać lokalnej godziny jako jedynego klucza czasu ani podstawy do łączenia tabel. Jeżeli użytkownik ma widzieć czas lokalny, warto przechowywać równolegle: czas UTC, czas lokalny oraz offset obowiązujący w danym momencie (np. +01:00 albo +02:00). Wtedy dwie pozornie identyczne godziny lokalne da się rozróżnić właśnie po offsecie, bo reprezentują różne chwile w UTC.

Jeżeli źródło dostarcza już tylko czas lokalny bez informacji o strefie lub offsecie, to przy godzinie powtórzonej po zmianie na czas zimowy nie da się zawsze odtworzyć poprawnej kolejności w sposób pewny. W takiej sytuacji trzeba pozyskać dodatkowy atrybut techniczny, np. identyfikator zdarzenia, kolejność zapisu lub oryginalny timestamp systemowy. Bez tego dwie wartości lokalne mogą być nierozróżnialne.

Kluczowe jest więc nie „usuwanie” podwójnych godzin, tylko modelowanie czasu tak, aby każda obserwacja była unikalna mimo DST. UTC zapewnia spójność obliczeń, a czas lokalny pozostaje wygodnym formatem do prezentacji dla użytkownika.

💡 Protip: Przy DST nie traktuj lokalnej godziny jako unikalnego klucza, bo np. 02:30 może oznaczać dwa różne zdarzenia. Zachowuj równolegle UTC i offset, dzięki czemu unikniesz podwójnych godzin, błędnej deduplikacji i złego sortowania.

Jak poprawnie liczyć metryki „per dzień”, gdy dzień zależy od strefy użytkownika?

Trzeba najpierw ustalić, że „dzień” nie może być liczony wyłącznie z daty zapisanej w UTC, jeśli raport ma być interpretowany z perspektywy użytkownika. Zdarzenie zarejestrowane np. o 23:30 UTC może należeć do jednego dnia w Londynie, a do następnego w Europie Środkowej czy Azji. Dlatego metryki typu liczba zdarzeń dziennie, aktywni użytkownicy per dzień czy przychód per dzień powinny być przypisywane do lokalnej daty użytkownika, wyliczonej z pełnego znacznika czasu, a nie z samej kolumny daty technicznej.

W praktyce poprawne liczenie polega na tym, że dla każdego rekordu najpierw przelicza się timestamp na strefę właściwą dla użytkownika lub dla kontekstu raportu, a dopiero potem wyodrębnia się z niego datę lokalną. Innymi słowy: kolejność musi być taka sama zawsze — UTC timestamp -> konwersja do strefy -> lokalna data -> agregacja per dzień. Jeśli najpierw odetniesz godzinę i zostawisz samą datę, a dopiero później spróbujesz uwzględnić strefę, wynik będzie błędny przy granicach dnia.

To ma szczególne znaczenie, gdy raport obsługuje wielu użytkowników w różnych strefach czasowych. Wtedy jedna uniwersalna tabela dat oparta na UTC nie wystarcza do wszystkich metryk „per dzień”, bo ten sam rekord może wpadać do innego dnia zależnie od odbiorcy raportu. Poprawny model musi więc opierać filtrowanie i agregację na dacie lokalnej wyznaczonej dla konkretnej strefy, a nie na jednej globalnej dacie systemowej.

Trzeba też uwzględnić zmianę czasu letniego i zimowego. Nie wolno zakładać stałego przesunięcia typu „UTC+1” przez cały rok, bo lokalna granica dnia może się przesuwać. Poprawne przypisanie rekordu do dnia wymaga użycia reguł strefy czasowej, a nie tylko prostego dodania liczby godzin.

Jeśli liczysz metryki historyczne, kluczowe jest zachowanie spójności definicji. Oznacza to, że ten sam wskaźnik powinien być zawsze liczony według tej samej zasady: albo per dzień użytkownika, albo per dzień referencyjnej strefy biznesowej. Najczęstszy błąd polega na mieszaniu tych podejść, przez co sumy dzienne, trendy i porównania między raportami zaczynają się rozjeżdżać mimo identycznych danych źródłowych.

Jak strefa czasowa wpływa na incremental refresh i okna inkrementacji?

Strefa czasowa wpływa bezpośrednio na to, które rekordy trafią do partycji odświeżanych inkrementalnie, ponieważ okna incremental refresh są wyznaczane względem wartości daty i czasu używanych w filtrze, najczęściej RangeStart i RangeEnd. Jeśli dane źródłowe są zapisane w jednej strefie czasowej, a logika odświeżania działa w innej, granice okna mogą przesunąć się o kilka godzin. W praktyce oznacza to, że część danych może zostać pobrana dwa razy, pominięta albo przypisana do niewłaściwej partycji.

Największy problem pojawia się na granicach dni i miesięcy oraz przy zmianie czasu letniego i zimowego. Przykładowo, jeżeli źródło zapisuje znaczniki czasu w UTC, a filtrowanie odbywa się według czasu lokalnego, to rekordy z przedziału około północy mogą wejść do innego okna niż oczekiwano. To zaburza spójność historii i bieżących przyrostów, zwłaszcza gdy model zakłada odświeżanie tylko ostatnich dni, a starsze partycje pozostają zamrożone.

Żeby okna inkrementacji działały poprawnie, trzeba stosować jedną, konsekwentną strefę odniesienia po obu stronach filtra: w źródle danych, w transformacjach i w warunku opartym o RangeStart/RangeEnd. Najbezpieczniejszym podejściem jest filtrowanie po czasie znormalizowanym do UTC albo po wcześniej przeliczonej kolumnie, której interpretacja strefy jest jednoznaczna. Kluczowe jest to, aby porównywać wartości tego samego typu i w tej samej strefie, a nie mieszać czasu lokalnego z UTC.

Jeśli po zmianie strefy czasowej odświeżanie zaczyna zwracać rozjazdy, należy zakładać, że problem dotyczy właśnie granic okien inkrementacji. Wtedy trzeba zweryfikować, jak wyznaczane są daty graniczne i czy rekord na granicy przedziału jest oceniany według tej samej strefy co partycja. Bez tego incremental refresh może działać technicznie poprawnie, ale biznesowo zwracać niepełne lub zdublowane dane.

💡 Protip: W incremental refresh filtruj dane w tej samej strefie czasowej, w której zapisane są wartości używane przez RangeStart i RangeEnd — najlepiej w UTC po obu stronach porównania. Szczególnie sprawdzaj rekordy na granicach dni i miesięcy, bo to tam najczęściej pojawiają się duplikaty albo braki.

Jak szybko zweryfikować i udokumentować źródło rozjazdu, żeby zamknąć temat na stałe?

Najszybsza metoda to porównać ten sam rekord na całej ścieżce przetwarzania: w źródle, w warstwie importu do Power BI, po transformacjach i w finalnym modelu. Trzeba sprawdzić przede wszystkim pola daty i czasu oraz odpowiedzieć na trzy pytania: jaka była wartość oryginalna, w jakiej strefie lub konwencji została zapisana oraz w którym miejscu została przesunięta lub zinterpretowana inaczej. Jeśli różnica pojawia się już między systemem źródłowym a Power Query, problem leży zwykle w imporcie albo typowaniu danych. Jeśli dopiero między Power Query a modelem lub wizualizacją, przyczyną jest najczęściej transformacja, relacja, agregacja albo użycie lokalnego czasu zamiast UTC.

Żeby temat zamknąć trwale, nie wystarczy stwierdzić, że „godzina się nie zgadza”. Trzeba zapisać jednoznaczny łańcuch dowodowy: identyfikator rekordu, wartość źródłową, typ danych w źródle, sposób interpretacji strefy czasowej, wartość po imporcie, wartość po transformacji i wartość końcową widoczną w raporcie. Najlepiej udokumentować to na 2–3 reprezentatywnych przykładach: rekord standardowy, rekord z dnia zmiany czasu oraz rekord z pogranicza daty. Taki zestaw pozwala wykazać, czy problem dotyczy wszystkich danych, tylko okresu DST, czy wyłącznie konkretnego źródła.

W dokumentacji warto zapisać także decyzję naprawczą w formie reguły, a nie jednorazowej poprawki, na przykład: wszystkie znaczniki czasu przechowujemy w UTC, a konwersja do czasu lokalnego następuje wyłącznie na warstwie prezentacji albo kolumna X jest traktowana jako czas lokalny i przed załadowaniem otrzymuje jawne przesunięcie. Dzięki temu przy kolejnym rozjeździe da się od razu sprawdzić zgodność z ustaloną zasadą, zamiast ponownie analizować cały przepływ danych. Kluczowe jest więc nie tylko znalezienie miejsca błędu, ale opisanie: gdzie powstał, dlaczego powstał, jak został potwierdzony i jaka reguła zapobiega jego powtórzeniu.

Majczęściej zadawane pytania i odpowiedzi odnośnie Rozjazdy danych po zmianie strefy czasowej: jak naprawić spójność w Power BI

Skąd mam wiedzieć, czy problem dotyczy strefy czasowej, a nie błędu w danych źródłowych?

Najpierw porównaj ten sam rekord w źródle, Power Query i finalnym modelu Power BI. Jeśli identyfikator rekordu się zgadza, ale różni się dzień, godzina albo przypisanie do zakresu raportowego, problem zwykle wynika z interpretacji czasu. Szczególnie podejrzane są rozbieżności pojawiające się przy północy, filtrach względnych i dniach zmiany czasu letniego lub zimowego.

Czy sama zmiana typu z DateTime na DateTimeZone może zmienić wyniki w raporcie?

Tak, sama zmiana typu danych może przesunąć moment zdarzenia i zmienić wyniki raportu. DateTime przechowuje lokalną datę i godzinę bez strefy, a DateTimeZone zawiera także przesunięcie względem UTC. Gdy konwersja między tymi typami nastąpi bez jasnej reguły, rekord może trafić do innego dnia, filtra albo agregacji niż w systemie źródłowym.

Jakie objawy najczęściej wskazują na rozjazd danych po zmianie strefy czasowej w Power BI?

Najczęściej widać różnice w sumach, licznościach i danych dziennych względem źródła. Typowe sygnały ostrzegawcze to:

rekordy wpadające do innego dnia lub miesiąca,
różne wyniki dla filtrów „dzisiaj”, „wczoraj” i „ostatnie 24 godziny”,
duplikaty albo braki przy granicach dnia,
problemy nasilające się w okresie zmiany czasu letniego i zimowego.

Czy mogę naprawić rozjazdy danych przez dodanie stałej liczby godzin do timestampu?

Nie, stałe dodanie kilku godzin zwykle nie rozwiązuje problemu poprawnie. Taki skrót może działać tylko pozornie i tylko dla części okresu. Przy zmianie czasu letniego i zimowego offset nie jest stały, więc proste przesunięcie psuje granice dni, błędnie przypisuje rekordy do dat i może zaburzyć metryki liczone historycznie.

Czy lokalna data biznesowa powinna być przechowywana osobno od czasu UTC?

Tak, w części procesów warto przechowywać lokalną datę biznesową obok czasu UTC. UTC powinno pozostać technicznym źródłem prawdy dla momentu zdarzenia, ale lokalna data bywa potrzebna w analizach rozliczanych według dnia roboczego, godzin działania lub reguł obowiązujących w danej strefie. Dzięki temu raport pozostaje jednoznaczny technicznie i użyteczny biznesowo.

Na co uważać przy łączeniu tabel po dacie i godzinie w modelu Power BI?

Nie łącz tabel wyłącznie po lokalnej godzinie, jeśli dane mogą przechodzić przez różne strefy lub DST. Bezpieczniej opierać relacje i klucze na jednoznacznym czasie referencyjnym. Szczególnie ryzykowne są lokalne godziny występujące dwa razy lub niewystępujące wcale. W praktyce najlepiej używać czasu UTC, a lokalny widok zostawić do prezentacji i analiz użytkownika.

Jak uporządkować model, jeśli raport ma pokazywać czas lokalny, ale liczyć dane spójnie?

Najlepiej rozdzielić warstwę techniczną od warstwy prezentacyjnej. Dobry układ obejmuje:

czas UTC jako bazę do przechowywania i łączenia danych,
jasną regułę konwersji do strefy lokalnej,
lokalną datę wyliczaną dopiero po konwersji,
metryki oparte na jednej, konsekwentnej definicji dnia.

Taki model ogranicza rozjazdy między źródłem, odświeżaniem i raportem.

Jak przygotować krótką dokumentację, żeby ten sam problem ze strefą czasową nie wrócił?

Najlepsza dokumentacja opisuje konkretny rekord, miejsce przesunięcia i stałą regułę naprawczą. W praktyce zapisz identyfikator przykładowego rekordu, wartość czasu w źródle, sposób interpretacji strefy, wynik po imporcie i wynik końcowy w raporcie. Na końcu dodaj jedną obowiązującą zasadę, na przykład przechowywanie czasu w UTC i lokalną konwersję wyłącznie na etapie prezentacji.