Zegar brokera to nie UTC
10 min czytania · Opublikowano 28.10.2026
Godzina przy świecy na wykresie to godzina serwera brokera, a nie czas uniwersalny ani polski. W ciągu trzech miesięcy pomyliliśmy te zegary co najmniej dziewięć razy: w backtestach, w automatach działających na żywo, a nawet we własnej regule, która miała nas przed tym chronić. W teście wybicia sesji nowojorskiej błąd przesunął wszystkie sesje o 2–3 godziny i zdradził się dziwną liczbą: strategia dała 3 transakcje, a placebo 127. Najtańszą kontrolą okazało się pytanie, o której godzinie złoto rusza się najmocniej.
Skróty: UTC to czas uniwersalny, od którego liczy się wszystkie strefy czasowe. Placebo to ta sama procedura w chwilach, w których badanej przyczyny nie ma. R to wynik transakcji w jednostkach ryzyka (−1 R = strata równa odległości do stopu). M5 to świece pięciominutowe. Czas letni w USA i w Europie zaczyna się i kończy w różne dni.
Założenie, którego nikt nie sprawdza
Platforma transakcyjna zapisuje przy każdej świecy datę i godzinę jako liczbę sekund od 1 stycznia 1970 roku, czyli w tym samym formacie co prawdziwy czas uniwersalny. Naturalne jest więc założenie, że to UTC. Tymczasem w danych z terminala siedzą cyfry z zegara ściennego serwera brokera, opisane tak, jakby były czasem UTC. Żaden program nie zgłosi przy tym błędu. Liczba wygląda poprawnie, daty się zgadzają, przesunięte są tylko godziny.
U naszego brokera serwer chodzi według zasady „Nowy Jork + 7 godzin”. To popularna konwencja: północ serwera wypada o 17:00 w Nowym Jorku, kiedy kończy się doba na rynku walutowym, więc tydzień ma pięć świec dziennych, bez krótkiej świecy niedzielnej. Zimą daje to UTC+2, latem UTC+3, a zmiana czasu następuje razem z USA, nie z Europą.
W jednym teście potrafią spotkać się cztery zegary:
- zegar serwera brokera, w którym są świece i ticki;
- prawdziwy UTC, w którym są dane z giełd, zewnętrzne kalendarze i zegar systemowy;
- strefa komputera, na którym działa program (u nas czas środkowoeuropejski);
- kalendarz ekonomiczny wbudowany w terminal, który u nas zapisuje godziny w stałym UTC+3 przez cały rok, więc zimą jest o godzinę „później” niż świece.
Dla tradera z Polski różnica też nie jest stała. Przez większość roku serwer jest godzinę przed czasem polskim, ale przez 3–4 tygodnie w roku (w marcu oraz na przełomie października i listopada), gdy USA i Europa mają różny czas, różnica wynosi dwie godziny. Raport z amerykańskiego rynku pracy wychodzi zawsze o 8:30 w Nowym Jorku i o 15:30 na zegarze serwera, ale w Polsce raz o 14:30, a raz o 13:30.
Jak to wyszło na jaw
Test wybicia zakresu otwarcia na złocie (22.09.2026). Opisujemy go w rozdziale 10. Sesje zapisaliśmy w UTC: Londyn od 8:00, Nowy Jork od 13:30. Pierwszy przebieg potraktował czas świec jak UTC. Sesja nowojorska dała 3 transakcje w sześć lat, a placebo, czyli ta sama reguła na zakresie z 16:30, dało ich 127. Gdy placebo jest czterdzieści razy „aktywniejsze” od sygnału, problem leży w pomiarze, a nie w rynku.
Wyjaśnienie było proste. Nasza „13:30 UTC” była w rzeczywistości godziną 13:30 na zegarze serwera, czyli 6:30 w Nowym Jorku i 12:30 w Polsce: spokojna pora przed otwarciem Ameryki, z wąskimi zakresami, które prawie nigdy nie przechodziły filtra szerokości. Z kolei 16:30 na zegarze serwera to dokładnie 9:30 w Nowym Jorku, czyli otwarcie tamtejszej giełdy akcji. Placebo trafiało więc w prawdziwe otwarcie, a „sygnał” w ciszę. Błąd zdradziła kontrola, którą od tej pory robimy przy każdym teście sesyjnym: szczyt zmienności złota wypadał według zegara serwera o 16:00, a po przeliczeniu na UTC około 14:00, w godzinach publikacji danych i otwarcia handlu w Nowym Jorku.
Test zaskoczenia danymi makro (17.09.2026, błąd znaleziony 27.10). Opisujemy go w rozdziale 26. Kalendarz z terminala zapisuje godziny w stałym UTC+3. Latem zgadza się to ze świecami, zimą już nie. Raport z rynku pracy USA zawsze wychodzi o 15:30 na zegarze serwera, a w naszym pliku stał o 16:30 w styczniu, lutym i na początku marca. W 39 z 90 zdarzeń próby naukowej mierzyliśmy więc okno, które zaczynało się godzinę po publikacji. Kontrola zegara przed testem dała 19 zgodności na 19, ale objęła tylko sierpień i wrzesień. W pełnym zrzucie kalendarza z lat 2017–2026 ten sam raport stał przed korektą o 16:30 aż 80 razy, a po korekcie o 15:30 w 115 przypadkach na 116.
Automat do skalpowania publikacji (20.08.2026). Działał w trybie obserwacji, bez zleceń. Porównywał godziny z kalendarza, zapisane w czasie serwera, z zegarem komputera, który był godzinę do tyłu. Uzbrajał się więc dokładnie godzinę po publikacji. Zauważył to właściciel systemu: automat uzbroił się o 15:30, a dane wyszły o 14:30.
Zanim błąd wyszedł na jaw, cztery „spóźnione” obserwacje okazały się zyskowne. Powstała z tego hipoteza, że godzinę po danych rynek kontynuuje ruch. Sprawdziliśmy ją z kryteriami zapisanymi przed testem, na 120 zdarzeniach i dwóch instrumentach. Wejście godzinę po publikacji dało średnio −0,15 R na złocie i −0,31 R na bitcoinie, czyli gorzej niż placebo dwie godziny przed publikacją (−0,06 R i +0,03 R). Cztery zyskowne obserwacje były zwykłym szczęściem. Pisząc ten rozdział, znaleźliśmy w tamtym teście drobniejszy błąd tej samej rodziny. Zdarzenia przeliczano przez europejską strefę czasu, więc 10 ze 120 (te z tygodni między zmianą czasu w USA i w Europie) trafiło godzinę przed właściwą chwilą. Wniosku to nie zmienia, ale dobrze pokazuje, jak uparty jest ten błąd.
Nasza własna reguła (25.09.2026). Po teście z 22.09 zapisaliśmy w zasadach, że zegar serwera przeliczamy przez strefę ateńską, czyli UTC+2 lub UTC+3 z europejską zmianą czasu. Trzy dni później porównaliśmy godzinowe zmiany ceny złota u brokera z kontraktem terminowym na złoto, którego czas giełda podaje w prawdziwym UTC, na około 38 tysiącach godzin z lat 2020–2026. W marcu, październiku i listopadzie zasada „Nowy Jork + 7 h” dopasowywała obie serie wyraźnie lepiej (mediana rozbieżności 0,18 wobec 0,28), a w pozostałych miesiącach oba warianty wypadały tak samo. Nasza reguła myliła się więc o godzinę przez 21–28 dni w roku; w 2026 roku były to dni 8–28 marca i 25–31 października.
Wynik: dziewięć pomyłek jednej rodziny
| kiedy (2026) | gdzie | co pomyliliśmy | skutek | jak wyszło na jaw |
|---|---|---|---|---|
| 28–29.07 | kod działającego systemu (6 miejsc) | czas świecy wzięty za prawdziwy UTC i dodatkowo przesunięty o strefę komputera | godziny przesunięte o 5 h, transakcje przypisane do złych dni | m.in. rozliczenie dnia niezgodne z saldem rachunku (04.08) |
| 20.08 | automat skalpujący publikacje (obserwacja) | kalendarz w czasie serwera kontra zegar komputera | uzbrojenie godzinę po danych; 4 fałszywie zyskowne obserwacje | właściciel systemu porównał godziny |
| 30.08 | zamykanie pozycji przed weekendem | harmonogram w czasie komputera, rynek w czasie serwera | start 46 minut po zamknięciu rynku; odrzucone zlecenia bez śladu w logu przez kilka tygodni | analiza odrzuceń „rynek zamknięty” |
| 17.09 | test zaskoczenia makro | kalendarz (stałe UTC+3) wzięty za zegar świec | zimą okno godzinę po publikacji: 39 z 90 zdarzeń | lektura kodu przy pisaniu rozdziału 26 |
| 22.09 | test wybicia otwarcia na złocie | czas świecy wzięty za UTC | sesje przesunięte o 2–3 h; sygnał 3 transakcje, placebo 127 | dziwne liczebności i szczyt zmienności o 16:00 |
| 25.09 | nasza reguła z 22.09 | strefa ateńska zamiast „Nowy Jork + 7 h” | błąd 1 h przez 3–4 tygodnie w roku | porównanie z kontraktem terminowym |
| 02.10 | pobieranie ticków do jednego przykładu | data bez strefy w zapytaniu, program przyjął czas komputera | okno 2 h za wcześnie; „cel trafiony” przed wejściem | godzina wyniku wypadła przed wejściem |
| 06.10 | ten sam automat skalpujący | kalendarz zewnętrzny UTC+3 na sztywno, „teraz” w strefie europejskiej | od 25.10 do marca znów uzbrajałby się godzinę po danych | przegląd kodu przed zmianą czasu |
| 27.10 | test wybicia otwarcia (ponowna lektura) | godziny sesji w stałym UTC przez cały rok | w 59 % dni „Londyn” zaczynał się godzinę po otwarciu, w 35 % dni „Nowy Jork” wypadał na minutę publikacji danych | lektura kodu przy pisaniu rozdziału 10 |
Dwa przypadki z tabeli zmieniły wynik testu na tyle, że jego wniosek przestał być ważny (17.09 i pierwszy przebieg z 22.09). Dwa dotyczyły działającego systemu: rozliczeń dnia (28.07) i zamykania pozycji przed weekendem (30.08). Pozostałe wyłapaliśmy, zanim wpłynęły na decyzję, ale wyłącznie dzięki temu, że coś wyglądało dziwnie.
Dlaczego ten błąd wraca
Nie zgłasza wyjątku. Program działa, liczby są wiarygodne, sesje istnieją, tylko leżą w złym miejscu. Wynik z przesuniętej sesji nie jest absurdalny, jest po prostu wynikiem innej strategii.
Często siedzi w porze roku, której nie sprawdzono. Błąd kalendarza występował tylko zimą, a kontrola objęła lato. Błąd strefy ateńskiej trwa 3–4 tygodnie w roku. Sprawdzenie jednego dnia albo jednego miesiąca tego nie złapie.
Poprawka bywa częściowa. Po poprawce z 20.08 automat liczył „teraz” w europejskiej strefie, więc od końca października znów uzbrajałby się godzinę po danych (wyłapane 06.10), a test napisany tego samego dnia przesunął 10 zdarzeń na 120. Reguła z 22.09 naprawiła błąd 2–3 godzin, ale zostawiła błąd godzinowy na kilka tygodni w roku. Za każdym razem uznawaliśmy temat za zamknięty.
Wiedza nie stała się regułą. O tym, że czas z terminala to zegar serwera opisany jak UTC, wiedzieliśmy od lipca. Raport z jednego z testów z 14.08 pisał o tym wprost, i tamten test liczył poprawnie. Ta wiedza została jednak w jednym raporcie i nie trafiła do listy zasad, więc 22.09 popełniliśmy ten błąd od nowa i „odkryliśmy” go drugi raz. Od tego dnia obowiązuje u nas zasada: lekcja z raportu trafia na listę reguł albo przepada.
Kontrola szczytu zmienności łapie duże błędy, ale nie małe. Szczyt liczony w UTC z całej próby, z latem i zimą razem, wypada we właściwym miejscu także wtedy, gdy przez kilka tygodni w roku zegar myli się o godzinę. Przesunięcie o 2–3 godziny widać od razu. Godzinę, która dotyczy części roku, widać dopiero w kontroli zrobionej osobno dla każdej pory roku.
Lekcja dla Ciebie
Jeśli Twoja strategia ma cokolwiek wspólnego z godziną (sesja, otwarcie, publikacja danych, „nie handluję w nocy”), zegar jest pierwszym podejrzanym, zanim zaczniesz oceniać wynik.
Jak sprawdzić zegar u siebie:
- Porównaj godzinę bieżącej świecy z prawdziwym czasem UTC z dowolnego wiarygodnego zegara internetowego. Zrób to teraz i jeszcze raz po zmianie czasu w USA i w Europie.
- Znajdź szczyt zmienności osobno latem i zimą, w czasie nowojorskim. Policz średni zasięg świecy M5 w każdym półgodzinnym okienku. Dla złota i indeksów USA szczyt powinien w obu porach roku wypaść między 8:30 a 10:00 czasu nowojorskiego. W jednym z naszych późniejszych testów podobny pomiar (liczba ticków), zrobiony osobno dla lata i zimy, pokazał szczyt aktywności na otwarciu indeksów USA o 16:30 serwera w obu porach roku, czyli dokładnie tam, gdzie powinien.
- Użyj znanego wydarzenia jako wzorca. Raport z rynku pracy USA wychodzi zawsze o 8:30 w Nowym Jorku. Sprawdź kilka dat zimą, latem i w tygodniach między zmianami czasu.
- Traktuj kalendarz i wykres jako dwa różne źródła. Jeśli publikacja „przesuwa się” w kalendarzu o godzinę między porami roku, kalendarz i świece są w różnych strefach i jedno trzeba przeliczyć na drugie.
- Zapisuj sesje w czasie lokalnym giełdy, z jej zmianą czasu. Godzina w UTC ustawiona na cały rok to w praktyce dwie różne sesje, letnia i zimowa.
- W każdym zapytaniu o dane podawaj strefę jawnie, a po pobraniu wypisz pierwszy i ostatni czas danych i porównaj je z oczekiwanym oknem.
- Gdy liczebność wygląda dziwnie, najpierw sprawdź zegar. Sygnał z 3 transakcjami obok placebo z 127 to objaw błędu pomiaru, a nie cecha rynku.
W dzienniku tradera zapisuj godziny transakcji w jednej, nazwanej strefie, na przykład w czasie polskim albo UTC, i dopisz, w jakiej. Bez tego porównanie wyników z sesjami albo z godzinami publikacji jest pomiarem w złym miejscu. Kalkulator „Szczęście czy przewaga?” pomoże potem ocenić, czy różnica między sesjami wykracza poza przypadek.
Materiał edukacyjny, nie porada inwestycyjna. Wyniki historyczne nie gwarantują przyszłych. Opisujemy błędy w naszych testach i w naszym systemie, na naszych danych i u naszego brokera; konwencja zegara serwera może być u innego brokera inna.