W nocy z soboty na niedzielę, z 24 na 25 października 2026, o 3:00 cofniemy zegarki na 2:00. Dostaniemy godzinę snu więcej, a doba będzie miała 25 godzin.
Z tego wynika coś, o czym rzadko się myśli: godzina 2:30 zdarzy się tej nocy dwa razy. Najpierw jako 2:30 czasu letniego, a godzinę później — znowu jako 2:30, tym razem czasu zimowego.
Człowiek wzruszy ramionami. Ale wyobraź sobie, że ktoś zarezerwował na Twojej stronie termin na 2:30 w tę niedzielę. Którą 2:30? Ty nie musisz znać odpowiedzi. Twoja strona — tak.
Spokojnie: większości stron nic się nie stanie. Jest jednak kilka miejsc, w których jedno ustawienie decyduje, czy przez całą zimę wszystko będzie się zgadzać, czy spieszyć o godzinę. Przejdźmy przez nie po kolei: od tego, co sprawdzisz w 30 sekund, po to, czego nie widać na pierwszy rzut oka.
Czy WordPress sam przestawi zegarek?
Tak — jeśli wcześniej mu na to pozwoliłeś. Wszystko zależy od jednego pola w ustawieniach.
Strefę czasową ustawia się w Ustawienia → Ogólne → Strefa czasowa. Na liście są dwa rodzaje opcji, które wyglądają podobnie, ale działają zupełnie inaczej:
- Miasto, np. „Warszawa”. To strefa z kalendarzem zmian. Strona wie, że 25 października przechodzi na czas zimowy, a w marcu wraca na letni.
- Liczba, np. „UTC+2”. To sztywne „zawsze dwie godziny od Greenwich”, bez żadnego kalendarza.
Skąd w ogóle ktoś wybiera UTC+2? Bo latem to się zgadza. Polska ma czas standardowy UTC+1, a UTC+2 obowiązuje tylko latem.
Jeśli strona powstawała w lipcu, ktoś sprawdził, ile mamy względem UTC, i wpisał dwójkę. Wszystko działało — przez całe lato. Problem zacznie się po cichu w niedzielę: od tej chwili strona będzie się spieszyć o godzinę, aż do końca marca.
Mały eksperyment myślowy
Dwie identyczne strony na WordPressie. Jedna ma ustawioną Warszawę, druga UTC+2. W poniedziałek 26 października o 9:00 otwierasz obie.
Pierwsza pokazuje 9:00. Druga — 10:00. Wpis zaplanowany na drugiej stronie na 10:00 właśnie się opublikował, choć Twoim zdaniem powinien poczekać jeszcze godzinę.
Test w 30 sekund
Wejdź w Ustawienia → Ogólne i spójrz na pole „Strefa czasowa”.
- Widzisz miasto? Wszystko w porządku. Przy strefie opartej na mieście WordPress pokazuje pod polem także termin najbliższej zmiany czasu (źródło).
- Widzisz „UTC+2” albo inną liczbę? Wybierz „Warszawa” i zapisz zmiany.
Po zmianie rzuć okiem na zaplanowane wpisy i promocje z datą końca. Zostały ustawione według starej strefy, więc warto sprawdzić, czy godziny nadal się zgadzają.
Nie masz WordPressa? Zasada jest ta sama: wszędzie, gdzie ustawia się strefę czasową, wybieraj miasto, nie liczbę. Kreatory stron mają to ustawienie w opcjach witryny. Strony na własnym kodzie mają je zwykle w kilku miejscach naraz, więc tu najlepiej zapytać osobę, która stronę robiła.
„Codziennie” znaczy „co 86 400 sekund”
To najciekawszy fragment całego tematu. Nawet jeśli masz ustawioną Warszawę, część zadań na stronie i tak przesunie się w niedzielę o godzinę.
WordPress ma wbudowany harmonogram zadań, czyli WP-Cron. Korzystają z niego wtyczki do kopii zapasowych, raportów, newsletterów i sprawdzania aktualizacji. Kiedy wtyczka ustawia zadanie „codziennie”, WordPress nie zapamiętuje „codziennie o 9:00”. Zapamiętuje konkretny moment w czasie uniwersalnym i dolicza do niego 86 400 sekund, czyli równo 24 godziny.
W zwykły dzień to jedno i to samo. Ale niedziela 25 października ma 25 godzin. Zadanie, które przez całe lato przychodziło o 9:00, od poniedziałku zacznie przychodzić o 8:00.
To nie teoria
Ktoś zgłosił to twórcom WordPressa ponad 14 lat temu, na przykładzie kopii zapasowej ustawionej na północ. Po zmianie czasu zaczęła się robić o 23:00 albo o 1:00. Zgłoszenie zamknięto po siedmiu latach z adnotacją, że brakuje zainteresowania obsługą czasu lokalnego w WP-Cronie (zgłoszenie #17957).
Jest też świeższy przykład z forum wsparcia. Użytkownik wtyczki bezpieczeństwa NinjaFirewall napisał, że po zmianie czasu dzienny raport przychodzi o 23:00 zamiast o północy. Autor wtyczki odpowiedział, że to normalne, bo harmonogram WordPressa liczy w UTC. Doradził wyłączenie i ponowne włączenie wtyczki. Efekt? Raport zaczął przychodzić o 2:00 w nocy (wątek na forum).
Czy to problem?
Zależy, co się przesuwa:
- Kopia zapasowa o 3:00 czy o 4:00? Raczej bez znaczenia.
- Raport „za wczorajszy dzień” wysyłany o północy? Tak, bo nagle obejmuje inny przedział godzin.
- Newsletter, który ma trafiać do skrzynek o 8:00? Zależy, czy wtyczka liczy czas sama, czy polega na WP-Cronie.
Jeszcze jeden szczegół: WP-Cron nie jest zegarem, który tyka sam z siebie. Uruchamia się dopiero wtedy, gdy ktoś odwiedzi stronę (dokumentacja). Na mało odwiedzanej stronie zadanie „na 9:00” może się więc wykonać o 9:40 — i to bez żadnej zmiany czasu.
Co zrobić: w poniedziałek sprawdź, o której przyszły automatyczne maile i raporty. Zaplanowane zadania podejrzysz bezpłatną wtyczką WP Crontrol. Jeśli godzina naprawdę ma znaczenie, zadanie lepiej powierzyć prawdziwemu harmonogramowi na serwerze, a nie WP-Cronowi.
Black Friday godzinę krócej
Wróćmy do strony z ustawionym UTC+2. Za pięć tygodni, w piątek 27 listopada, jest Black Friday. Sklep ustawia promocję „do 23:59”.
Strona się spieszy, więc jej 23:59 wypada o 22:59 naszego czasu. Klient, który wchodzi o 23:15, żeby zdążyć na ostatnią chwilę, widzi już zwykłe ceny. A ostatnia godzina dużej promocji to często moment, w którym niezdecydowani wreszcie klikają „kupuję”.
To samo dotyczy wszystkiego, co w sklepie ma datę i godzinę:
- kodów rabatowych z terminem ważności,
- automatycznego startu promocji „od północy”,
- dostępu do kursu lub produktu cyfrowego na określony czas,
- przypomnień o porzuconym koszyku,
- terminów odbioru i rezerwacji.
Warto to powiedzieć wprost: sam WooCommerce nie robi tu nic złego. Liczy czas według ustawień strony. Jeśli strefa jest dobrze ustawiona, promocja skończy się o 23:59. Ryzyko leży w złym ustawieniu i w dodatkach, które liczą czas po swojemu.
A rezerwacja na 2:30?
Większość firm nie przyjmuje klientów o tej porze, więc dla nich to problem teoretyczny. Inaczej jest z hotelami, wypożyczalniami czy usługami całodobowymi. Dobry system rezerwacji musi wiedzieć, o którą 2:30 chodzi — a nie zgadywać.
Doba, która ma 25 godzin
Google Analytics poradzi sobie ze zmianą czasu sam — pod warunkiem, że w ustawieniach usługi wybrano strefę „Polska”. Google pisze wprost, że jeśli strefa uwzględnia zmianę czasu, Analytics automatycznie się do niej dostosowuje (dokumentacja Google).
Dlatego najważniejsza rada brzmi: nie przestawiaj niczego ręcznie. Zmiana strefy działa tylko na dane od tego momentu, nie wstecz. W starszej wersji Analytics Google uprzedzał, że taka zmiana może dać na wykresie płaski odcinek albo nagły skok (pomoc Google).
Rekordowa niedziela, której nie było
Jest za to jedna rzecz, o której warto pamiętać przy czytaniu raportów. Niedziela 25 października ma 25 godzin, więc strona miała godzinę więcej na zbieranie odwiedzin.
Dodatkowa godzina wypada w nocy, więc różnica będzie niewielka. Ale jeśli w poniedziałek ktoś pokaże Ci wykres z „rekordową niedzielą”, zapytaj, czy rekord nie wziął się z dodatkowej godziny. W marcu będzie odwrotnie: doba będzie miała 23 godziny i niedziela wypadnie odrobinę słabiej.
Czego się nie bać
Wokół zmiany czasu krąży kilka obaw, które można spokojnie odłożyć.
- Certyfikat SSL nie zyska ani nie straci godziny. Daty jego ważności są zapisane w czasie uniwersalnym, w którym zmiany czasu po prostu nie ma.
- Cache nie będzie trzymał stron godzinę dłużej. Czas przechowywania liczy się w sekundach, a nie według zegara na ścianie.
- Sesje i logowanie nie wygasną wcześniej ani później. Tokeny i ciasteczka też liczą czas w sekundach albo w UTC.
- Pozycje w Google nie spadną. Sama zmiana czasu nie ma na nie wpływu.
Zasada jest prosta. Komputery w środku liczą czas w UTC, w sekundach od 1 stycznia 1970 roku. Zmiana czasu istnieje dopiero wtedy, gdy ten czas trzeba pokazać człowiekowi.
Kłopoty zaczynają się więc tam, gdzie ktoś zapisał godzinę „po ludzku” — bez informacji, o jaką strefę chodzi. I tu dochodzimy do najciekawszego miejsca.
A agent AI?
Tej części nie znajdziesz w typowym poradniku o zmianie czasu.
Twoją stronę coraz częściej czyta nie tylko człowiek. Czyta ją też ChatGPT, który sprawdza godziny otwarcia, albo asystent, który ma zarezerwować wizytę. Człowiek widzi „czynne od 9:00” i rozumie kontekst. Agent musi ten kontekst dostać w danych.
Weźmy termin z początku tekstu. Można go zapisać na trzy sposoby:
| Zapis | Co wie agent |
|---|---|
| 2026-10-25 02:30 | Nic pewnego. Nie wie, w jakiej strefie jest ta godzina. |
| 2026-10-25 02:30 Europe/Warsaw | Więcej, ale wciąż nie wie, o którą 2:30 chodzi. |
| 2026-10-25T02:30+02:00 lub 2026-10-25T02:30+01:00 | Wszystko. To dwa różne, jednoznaczne momenty. |
Dopiero trzeci zapis pozwala zarezerwować termin bez zgadywania. Godzina bez strefy to informacja niepełna. Godzina ze strefą nie zawsze jest jednoznaczna.
Koncert o 19:00, który agent widzi o 18:00
Druga pułapka jest bardziej przyziemna. Strony z wydarzeniami często mają w danych strukturalnych datę z wpisanym na sztywno przesunięciem „+02:00”. Latem wszystko się zgadza.
Ale koncert 15 listopada o 19:00 zapisany jako „19:00+02:00” to dla maszyny 18:00 naszego czasu. Człowiek na stronie widzi 19:00. Google i agent AI odczytują 18:00. Ktoś zapyta czat, o której zaczyna się koncert, i dostanie złą odpowiedź — choć na stronie wszystko wygląda dobrze.
To ten sam mechanizm, o którym pisaliśmy przy cenach: to, co widzisz na stronie, nie zawsze jest tym, co wychodzi na zewnątrz (42,90 zł na stronie, 135,00 zł w danych strukturalnych).
Tydzień, w którym Nowy Jork jest bliżej
Nie wszystkie kraje zmieniają czas tego samego dnia. W Unii Europejskiej i Wielkiej Brytanii zmiana następuje jednocześnie, ale Stany Zjednoczone cofają zegarki dopiero 1 listopada (źródło). Przez ten tydzień różnica między Polską a Nowym Jorkiem wynosi 5 godzin zamiast zwykłych 6.
Jeśli umawiasz spotkania z klientami zza oceanu, to dobry tydzień, żeby dwa razy sprawdzić godzinę w zaproszeniu. A jeśli Twoja strona pokazuje godziny w czasie odwiedzającego, to świetny moment na test, czy robi to dobrze.
Checklista: 5 rzeczy do sprawdzenia przed niedzielą
- Strefa czasowa strony. W WordPressie: Ustawienia → Ogólne. Powinno być miasto, nie liczba. Na innych platformach szukaj tego samego w ustawieniach witryny.
- Automatyczne maile i raporty. W poniedziałek sprawdź, o której przyszły. Przesunięcie o godzinę oznacza, że zadanie liczy „co 24 godziny”.
- Promocje i kupony z datą końca. Zwłaszcza te zaplanowane na Black Friday.
- System rezerwacji. Często ma własne ustawienie strefy, niezależne od strony.
- Konta w zewnętrznych narzędziach. Booksy, Calendly, system newslettera, Make czy Zapier mają własną strefę w ustawieniach konta. Wszędzie powinno być miasto.
A w Google Analytics? Niczego nie zmieniaj.
Czas jest prosty, dopóki nie próbujemy go zapisać
Zmiana czasu dobrze pokazuje, ile rzeczy na stronie zależy od jednej informacji: która jest godzina. Człowiek rozumie ją z kontekstu. Strona, wtyczka i agent AI rozumieją ją tylko wtedy, gdy ktoś zapisał ją porządnie.
Dobra wiadomość: porządne ustawienie robi się raz. Strona z wybranym miastem przetrwa każdą kolejną zmianę czasu. Przetrwałaby nawet jej zniesienie, bo reguły dla Warszawy leżą w światowej bazie stref czasowych, aktualizowanej razem z systemem. Strona z UTC+2 będzie wymagać ręcznej poprawki za każdym razem.
Nie wiesz, gdzie szukać tych ustawień, albo nie chcesz sprawdzać tego sam? Takimi rzeczami zajmujemy się w ramach opieki nad stroną. Napisz do nas — sprawdzimy strefę czasową, harmonogramy i dane strukturalne, zanim zrobi to Black Friday.