{"id":13164,"date":"2026-09-26T18:25:00","date_gmt":"2026-09-26T16:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13164"},"modified":"2026-09-25T15:07:51","modified_gmt":"2026-09-25T13:07:51","slug":"tutorial-piec-formatow-znacznika-czasu-w-stosie-pomiarowym-i-ich-przeliczanie","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/tutorials-pl\/tutorial-piec-formatow-znacznika-czasu-w-stosie-pomiarowym-i-ich-przeliczanie\/","title":{"rendered":"Tutorial: Pi\u0119\u0107 format\u00f3w znacznika czasu w stosie pomiarowym i ich przeliczanie"},"content":{"rendered":"

Jedno klikni\u0119cie wytwarza znacznik czasu w przegl\u0105darce, kolejny w mened\u017cerze tag\u00f3w, trzeci w eksporcie analitycznym i czwarty w platformie reklamowej, do kt\u00f3rej zostaje przekazany. Wszystkie cztery opisuj\u0105 t\u0119 sam\u0105 chwil\u0119. \u017baden nie jest zapisany tak samo.<\/p>\n

Najwi\u0119ksza cz\u0119\u015b\u0107 zamieszania rozwi\u0105zuje si\u0119 przez policzenie cyfr. Cz\u0119\u015b\u0107 pozosta\u0142a to granica dnia – a t\u0119 warto pozna\u0107, zanim jeden raport zostanie zestawiony z drugim.<\/p>\n

\n\"Pi\u0119\u0107
Ta sama chwila w pi\u0119ciu zapisach. O\u015b poni\u017cej pokazuje przypadek, w kt\u00f3rym dwa z nich nie zgadzaj\u0105 si\u0119 co do daty.<\/figcaption><\/figure>\n

Pi\u0119\u0107 format\u00f3w spotykaj\u0105cych si\u0119 w jednym stosie<\/h2>\n

Wszystkie licz\u0105 od tego samego punktu zerowego: p\u00f3\u0142nocy 1 stycznia 1970 roku w UTC. R\u00f3\u017cni\u0105 si\u0119 jednostk\u0105 i opakowaniem.<\/p>\n\n\n\n\n\n\n\n\n\n
Format<\/th>\nPrzyk\u0142ad<\/th>\nGdzie wyst\u0119puje<\/th>\n<\/tr>\n<\/thead>\n
Sekundy<\/td>\n1790465400<\/td>\nMeta CAPI event_time, wi\u0119kszo\u015b\u0107 interfejs\u00f3w REST<\/td>\n<\/tr>\n
Milisekundy<\/td>\n1790465400000<\/td>\nDate.now(), gtm.start, wi\u0119kszo\u015b\u0107 JavaScriptu<\/td>\n<\/tr>\n
Mikrosekundy<\/td>\n1790465400000000<\/td>\nGA4 BigQuery event_timestamp<\/td>\n<\/tr>\n
ISO 8601<\/td>\n2026-09-27T01:30:00+02:00<\/td>\nDzienniki, API Search Console, wi\u0119kszo\u015b\u0107 eksport\u00f3w<\/td>\n<\/tr>\n
Sama data<\/td>\n20260927<\/td>\nGA4 event_date, sufiks tabeli BigQuery<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Trzy pierwsze s\u0105 jednoznaczne: to liczba jednostek od sta\u0142ego punktu i nie nios\u0105 strefy czasowej, bo jej nie potrzebuj\u0105. Czwarty jest jednoznaczny, dop\u00f3ki niesie przesuni\u0119cie – to +02:00<\/code> na ko\u0144cu czyni z niego chwil\u0119, a nie opis.<\/p>\n

Pi\u0105ty jest innego rodzaju. Data bez godziny nie jest chwil\u0105, lecz zakresem dwudziestu czterech godzin – a kt\u00f3re to dwadzie\u015bcia cztery godziny, zale\u017cy od strefy czasowej, kt\u00f3rej w warto\u015bci nigdzie nie ma.<\/p>\n

Rozr\u00f3\u017cnienie przez policzenie cyfr<\/h2>\n

Dla liczby z dziennika, eksportu albo zawarto\u015bci rozstrzyga d\u0142ugo\u015b\u0107.<\/p>\n

10 cyfr   sekundy       1790465400          do roku 2286\n13 cyfr   milisekundy   1790465400000\n16 cyfr   mikrosekundy  1790465400000000\n 8 cyfr   data          20260927            wcale nie chwila<\/code><\/pre>\n
Z pomini\u0119cia tego bior\u0105 si\u0119 dwa b\u0142\u0119dy, a oba daj\u0105 wynik wygl\u0105daj\u0105cy wiarygodnie. Odczytanie milisekund jako sekund przesuwa dat\u0119 do roku 58 707 – b\u0142\u0105d oczywisty, a wi\u0119c nieszkodliwy. Odczytanie sekund jako milisekund przesuwa j\u0105 na 21 stycznia 1970, co oczywiste wcale nie jest, i pojawia si\u0119 w raporcie jako male\u0144ki s\u0142upek na lewym skraju ka\u017cdego wykresu.<\/p>\n
Zabezpieczenie kosztuje trzy linie i op\u0142aca si\u0119 wsz\u0119dzie tam, gdzie warto\u015b\u0107 przychodzi z zewn\u0105trz.<\/p>\n
def zu_sekunden(wert):\n    z = len(str(int(wert)))\n    if z == 16: return int(wert) \/ 1_000_000\n    if z == 13: return int(wert) \/ 1_000\n    if z == 10: return int(wert)\n    raise ValueError(f\"nieznany format czasu o {z} cyfrach: {wert}\")<\/code><\/pre>\n
Dzie\u0144, kt\u00f3ry nie jest tym samym dniem<\/h2>\n
Eksport GA4 do BigQuery niesie zar\u00f3wno chwil\u0119, jak i dat\u0119, a oba trzymaj\u0105 si\u0119 r\u00f3\u017cnych konwencji.<\/p>\n
event_timestamp<\/code> to mikrosekundy od epoki, a wi\u0119c UTC. event_date<\/code> to ci\u0105g postaci YYYYMMDD<\/code> w strefie raportowania us\u0142ugi. Przy us\u0142udze ustawionej na Berlin ka\u017cde zdarzenie mi\u0119dzy p\u00f3\u0142noc\u0105 a drug\u0105 w nocy czasu lokalnego niesie wi\u0119c dat\u0119 o dzie\u0144 dalsz\u0105 ni\u017c to, co m\u00f3wi w UTC jego w\u0142asny znacznik czasu.<\/p>\n
Zdarzenie 27.09.2026 o godzinie 01:30 czasu berlinskiego\n\nevent_date                                          20260927\nDATE(TIMESTAMP_MICROS(event_timestamp))           2026-09-26\nDATE(TIMESTAMP_MICROS(event_timestamp),\n     \"Europe\/Berlin\")                             2026-09-27<\/code><\/pre>\n
To nie jest usterka i nie da si\u0119 tego wy\u0142\u0105czy\u0107. To pow\u00f3d, dla kt\u00f3rego dwa zapytania po tej samej tabeli mog\u0105 da\u0107 r\u00f3\u017cne sumy dzienne – a r\u00f3\u017cnica ma zawsze ten sam rozmiar: zdarzenia z pierwszej jednej lub dw\u00f3ch godzin ka\u017cdego dnia.<\/p>\n
Wynikaj\u0105ca zasada jest kr\u00f3tka. Grupowanie po dniach u\u017cywa albo wsz\u0119dzie event_date<\/code>, albo wsz\u0119dzie DATE(..., \"Europe\/Berlin\")<\/code>, nigdy obu naraz – a zapytanie \u0142\u0105cz\u0105ce dwie tabele musi po obu stronach u\u017cy\u0107 tej samej konwencji. Sufiks tabeli _TABLE_SUFFIX<\/code> pod\u0105\u017ca za event_date<\/code>, przez co filtr daty na sufiksie i filtr na przeliczonym znaczniku czasu wybieraj\u0105 r\u00f3\u017cne wiersze.<\/p>\n
Przeliczanie w BigQuery<\/h2>\n
Trzy funkcje obejmuj\u0105 ka\u017cdy przypadek, a ka\u017cda nosi jednostk\u0119 w nazwie.<\/p>\n
SELECT\n  event_timestamp,\n  TIMESTAMP_MICROS(event_timestamp)                       AS moment_utc,\n  DATETIME(TIMESTAMP_MICROS(event_timestamp),\n           \"Europe\/Berlin\")                               AS ortszeit,\n  DATE(TIMESTAMP_MICROS(event_timestamp), \"Europe\/Berlin\") AS tag_lokal,\n  FORMAT_TIMESTAMP(\"%FT%T%Ez\",\n                   TIMESTAMP_MICROS(event_timestamp),\n                   \"Europe\/Berlin\")                       AS iso_mit_versatz,\n  UNIX_SECONDS(TIMESTAMP_MICROS(event_timestamp))         AS sekunden\nFROM `projekt.analytics_123456789.events_*`\nWHERE _TABLE_SUFFIX = \"20260927\"\nLIMIT 10;<\/code><\/pre>\n
R\u00f3\u017cnic\u0119 mi\u0119dzy TIMESTAMP<\/code> a DATETIME<\/code> warto sobie przyswoi\u0107. TIMESTAMP<\/code> jest chwil\u0105 i wie, czym jest; DATETIME<\/code> jest odczytem zegara bez strefy, a zamiana znacznika czasu w taki odczyt to dok\u0142adnie miejsce, w kt\u00f3rym informacja o strefie zostaje celowo odrzucona. Zapisany DATETIME<\/code> odczytany gdzie indziej to droga, kt\u00f3r\u0105 znika godzina.<\/p>\n
W drug\u0105 stron\u0119 z ci\u0105gu znak\u00f3w powstaje znacznik czasu wy\u0142\u0105cznie przy podanym formacie – a podanie formatu jest miejscem, w kt\u00f3rym przesuni\u0119cie zostaje albo odczytane, albo wymy\u015blone.<\/p>\n
PARSE_TIMESTAMP(\"%FT%T%Ez\", \"2026-09-27T01:30:00+02:00\")   -- poprawnie\nPARSE_TIMESTAMP(\"%FT%T\",     \"2026-09-27T01:30:00\")        -- odczytane jako UTC<\/code><\/pre>\n
Okna odrzucaj\u0105ce znacznik czasu<\/h2>\n
Dwa systemy odbieraj\u0105ce sprawdzaj\u0105 warto\u015b\u0107, zamiast tylko j\u0105 zapisa\u0107, i oba zawodz\u0105 w spos\u00f3b \u0142atwy do przeoczenia.<\/p>\n
Meta Conversions API przyjmuje event_time<\/code> z ostatnich siedmiu dni. Zdarzenie starsze zostaje odrzucone, a wsadowe przes\u0142anie historycznych konwersji traci przez to po cichu wszystko poza oknem – odpowied\u017a melduje, ile zdarze\u0144 odebrano, a nie ile zachowano. Sprawdzeniem jest liczba z odpowiedzi wobec liczby wys\u0142anych.<\/p>\n
Znacznik czasu w przysz\u0142o\u015bci to druga po\u0142owa tej samej zasady i zdarza si\u0119 cz\u0119\u015bciej ni\u017c przesz\u0142o\u015b\u0107: serwer z zegarem spiesz\u0105cym o kilka minut wytwarza zdarzenia, kt\u00f3re platforma odrzuca. Nieudane przes\u0142anie konwersji warto wi\u0119c bada\u0107 jako problem zegara, zanim zostanie zbadane jako problem danych.<\/p>\n
Przesy\u0142anie konwersji offline do platform reklamowych zwykle wymaga czasu lokalnego z wyra\u017anym przesuni\u0119ciem, a nie warto\u015bci epoki.<\/p>\n
2026-09-27 01:30:00+02:00<\/code><\/pre>\n
Przesuni\u0119cie nie jest ozdob\u0105. Bez niego platforma stosuje stref\u0119 czasow\u0105 konta, a konto w innej strefie ni\u017c sklep przesuwa ka\u017cd\u0105 konwersj\u0119 o t\u0119 r\u00f3\u017cnic\u0119 – co objawia si\u0119 konwersjami w b\u0142\u0119dnym dniu, a na granicy miesi\u0105ca w b\u0142\u0119dnym miesi\u0105cu.<\/p>\n
Dwie dwuznaczno\u015bci nie do naprawienia po fakcie<\/h2>\n
Wszystko powy\u017csze jest przeliczeniem. Te dwie s\u0105 stratami, a jedynym \u015brodkiem jest niedopuszczenie do ich powstania.<\/p>\n
Pierwsz\u0105 jest czas lokalny bez przesuni\u0119cia. 2026-09-27 01:30:00<\/code> nie jest chwil\u0105, lecz chwil\u0105 w jakiej\u015b strefie – a je\u017celi strefy nie zapisano, \u017cadne p\u00f3\u017aniejsze przetwarzanie jej nie odzyska. Domys\u0142 jest mo\u017cliwy i pozostaje domys\u0142em: ten sam ci\u0105g znak\u00f3w mo\u017ce oznacza\u0107 dwie chwile odleg\u0142e o godzin\u0119.<\/p>\n
Drug\u0105 jest noc zmiany czasu. Przy cofni\u0119ciu zegar\u00f3w godzina mi\u0119dzy drug\u0105 a trzeci\u0105 w nocy zdarza si\u0119 dwa razy, a czas lokalny w jej obr\u0119bie jest naprawd\u0119 dwuznaczny nawet przy znanej strefie. Przesuni\u0119cie to rozstrzyga, bo oba przebiegi maj\u0105 r\u00f3\u017cne przesuni\u0119cia. Sama nazwa strefy tego nie robi.<\/p>\n
Jedno i drugie znika, gdy warto\u015bci zapisywane s\u0105 jako UTC i przeliczane wy\u0142\u0105cznie do wy\u015bwietlenia. To zasada jednolinijkowa, brzmi\u0105ca oczywi\u015bcie i \u0142amana bez przerwy, bo czas lokalny to w\u0142a\u015bnie to, co cz\u0142owiek chce przeczyta\u0107 – a zaradza temu przeliczanie przy odczycie, a nie przy zapisie.<\/p>\n
\n
Pytania i odpowiedzi<\/h2>\n
Warto\u015b\u0107 ma 19 cyfr. Co to jest?<\/h3>\n
Najprawdopodobniej nanosekundy od epoki. Tego formatu u\u017cywaj\u0105 na przyk\u0142ad OpenTelemetry oraz funkcja UnixNano w Go; w stosie pomiarowym pojawia si\u0119 przede wszystkim w danych serwerowych i w dziennikach. Zabezpieczenie s\u0142usznie go odrzuca, zamiast zgadywa\u0107, a da si\u0119 je rozszerzy\u0107 o jedn\u0105 lini\u0119 dla 19 cyfr z dzielnikiem 1_000_000_000<\/code>.<\/p>\n
Czy JavaScript przetwarza 16-cyfrowe mikrosekundy bez straty?<\/h3>\n
Dzi\u015b tak, ale na styk. JavaScript przechowuje liczby jako warto\u015bci zmiennoprzecinkowe podw\u00f3jnej precyzji, a te odwzorowuj\u0105 liczby ca\u0142kowite dok\u0142adnie tylko do 9\u00a0007\u00a0199\u00a0254\u00a0740\u00a0991 (Number.MAX_SAFE_INTEGER<\/code>). Warto\u015b\u0107 w mikrosekundach z 2026 roku, 1\u00a0790\u00a0465\u00a0400\u00a0000\u00a0000, jest mniej wi\u0119cej pi\u0119\u0107 razy mniejsza; w mikrosekundach ta granica odpowiada rokowi 2255.<\/p>\n
Nanosekundy le\u017c\u0105 natomiast daleko ponad ni\u0105. Warto\u015b\u0107 19-cyfrowa traci przy wczytaniu przez JSON.parse<\/code> ostatnie cyfry, i to bez \u017cadnego b\u0142\u0119du. Gdy takie warto\u015bci s\u0105 potrzebne w JavaScripcie, najlepiej wczytywa\u0107 je jako ci\u0105gi znak\u00f3w i przekszta\u0142ca\u0107 przez BigInt<\/code> albo ju\u017c na serwerze przelicza\u0107 na milisekundy.<\/p>\n
Dlaczego nie ustawi\u0107 po prostu strefy czasowej us\u0142ugi na UTC?<\/h3>\n
Usuwa to r\u00f3\u017cnic\u0119 mi\u0119dzy event_date a znacznikiem czasu, ale przenosi problem w inne miejsce. Wszystkie raporty dzienne w GA4 zaczynaj\u0105 si\u0119 wtedy o p\u00f3\u0142nocy UTC, czyli dla sklepu w Berlinie o pierwszej w nocy zim\u0105 i o drugiej latem. Zakup o wp\u00f3\u0142 do pierwszej w nocy trafia do dnia poprzedniego, a warto\u015bci dzienne przestaj\u0105 zgadza\u0107 si\u0119 z kas\u0105, systemem magazynowym i kontami reklamowymi, kt\u00f3re licz\u0105 w czasie lokalnym.<\/p>\n
Do tego dochodzi sama zmiana. Nowa strefa raportowania obowi\u0105zuje tylko dla danych od chwili przestawienia, a wcze\u015bniejsze dni zostaj\u0105 takie, jakie by\u0142y. Dzie\u0144 zmiany jest wi\u0119c kr\u00f3tszy albo d\u0142u\u017cszy ni\u017c dwadzie\u015bcia cztery godziny, a szereg czasowy obejmuj\u0105cy zmian\u0119 zestawia dni berli\u0144skie z dniami UTC.<\/p>\n
Lepiej sprawdza si\u0119 zasada z artyku\u0142u: us\u0142uga zachowuje stref\u0119, w kt\u00f3rej liczy firma, a ka\u017cde zapytanie wybiera jedn\u0105 konwencj\u0119. Grupowanie w BigQuery wed\u0142ug dni berli\u0144skich ma wtedy te same granice dnia co interfejs, a grupowanie wed\u0142ug UTC jest \u015bwiadomym wyborem innego dnia.<\/p>\n
Jak potwierdzi\u0107, \u017ce za odrzuconym przes\u0142aniem stoi zegar serwera?<\/h3>\n
Dwoma sprawdzeniami. Na samym serwerze timedatectl<\/code> w Linuksie pokazuje, czy zegar jest synchronizowany z serwerem czasu; je\u015bli wiersz System clock synchronized ma warto\u015b\u0107 no, rozjechany zegar jest prawdopodobny. Drugie sprawdzenie nie wymaga dost\u0119pu do systemu operacyjnego: ka\u017cda odpowied\u017a HTTP platformy niesie w nag\u0142\u00f3wku Date<\/code> czas jej serwera, a por\u00f3wnanie z w\u0142asnym czasem w tej samej chwili pokazuje odchy\u0142k\u0119 z dok\u0142adno\u015bci\u0105 do oko\u0142o sekundy.<\/p>\n
Je\u015bli odchy\u0142ka si\u0119ga minut, znika, gdy tylko zacznie dzia\u0142a\u0107 synchronizacja z serwerem czasu. Zdarzenia ju\u017c wys\u0142ane z b\u0142\u0119dnym czasem i odrzucone nale\u017cy potem wys\u0142a\u0107 ponownie z poprawionym znacznikiem czasu, dop\u00f3ki mieszcz\u0105 si\u0119 w siedmiodniowym oknie.<\/p>\n<\/div>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n