Sedno problemu: zapis 02:30 nie identyfikuje chwili bez daty, miejsca i reguły strefy. Podczas zmiany czasu taka godzina może nie istnieć albo może oznaczać dwie różne chwile UTC.

Cztery informacje ukryte pod słowem czas

W obliczeniu trzeba rozdzielić:

• czas lokalny, czyli zapis widoczny na zegarze w danym miejscu,
• strefę, czyli zestaw reguł przypisanych do lokalizacji,
• offset, czyli przesunięcie względem UTC obowiązujące w konkretnej chwili,
• UTC, czyli jednoznaczny punkt odniesienia dla efemerydy.

Identyfikator Europe/Warsaw nie jest innym zapisem UTC+1. Pierwszy odsyła do historii zmian. Drugi opisuje tylko jedną wartość przesunięcia. Warszawa w różnych datach używała czasu standardowego, letniego oraz historycznych reguł, których nie można odtworzyć z aktualnego offsetu.

Przeliczenie może zmienić datę

Jeżeli lokalny czas jest dodatnio przesunięty względem UTC, odjęcie offsetu może przenieść chwilę na poprzedni dzień. Przykład: 1 stycznia, 00:20 przy UTC+2 odpowiada 31 grudnia, 22:20 UTC.

Nie oznacza to, że osoba urodziła się lokalnie dzień wcześniej. W nocie należy zachować obie wartości: źródłową datę cywilną oraz wynik UTC użyty do obliczeń. Mieszanie ich prowadzi do podwójnego przesunięcia.

Luka podczas przejścia na czas letni

29 marca 2026 r. w Warszawie zegary przechodzą z 02:00 na 03:00. Lokalny zapis 02:30 nie odpowiada żadnej rzeczywistej chwili w tej strefie. System przyjmujący go bez ostrzeżenia musi zastosować niejawne przesunięcie albo normalizację.

Prawidłowy interfejs powinien zatrzymać obliczenie i poprosić o weryfikację źródła. Nie wystarczy wybrać offset, ponieważ żadna z sąsiednich wartości nie czyni 02:30 istniejącym czasem lokalnym.

Podwójna godzina przy powrocie do czasu standardowego

25 października 2026 r. w Warszawie godzina od 02:00 do 02:59 występuje dwa razy. Zapis 02:30 może oznaczać chwilę z offsetem UTC+2 albo późniejszą z UTC+1. Wyniki różnią się o godzinę.

Do rozstrzygnięcia potrzebna jest dodatkowa informacja: jawny offset, kolejność wystąpienia, znacznik czasu z systemu szpitalnego albo inny dokument. Bez niej oba warianty powinny zostać policzone i opisane jako alternatywy.

Dlaczego skrót strefy nie wystarcza

Skróty takie jak CST, IST lub BST bywają używane w wielu regionach. Nie opisują też całej historii zmian granic i prawa. W dokumentacji obliczenia lepiej zapisać identyfikator lokalizacyjny IANA oraz wersję bazy, na przykład Europe/Warsaw, tzdb 2026d.

Baza IANA służy przede wszystkim do opisu czasu cywilnego używanego przez komputery. Jej dane sprzed 1970 r. mogą być mniej kompletne, a rekonstrukcje historyczne bywają korygowane. Brak zmiany w pliku nie jest automatycznie dowodem, że lokalna praktyka była jednolita.

Dawny czas miejscowy

Przed standaryzacją stref wiele miejsc stosowało średni czas miejscowy oparty na długości geograficznej. Źródło może podawać godzinę według zegara lokalnego, czasu kolejowego, miejskiego albo już państwowego. Nazwa miejscowości nie rozstrzyga sama, której konwencji użyto.

Dla starej daty należy szukać dokumentacji właściwej dla kraju i instytucji, a nie tylko współczesnego identyfikatora. Jeśli brak danych, raport powinien podać przyjętą hipotezę oraz możliwy błąd w minutach.

Kalendarz jest osobnym ustawieniem

Data historyczna może być zapisana w kalendarzu juliańskim albo gregoriańskim. Reforma nie została przyjęta jednocześnie we wszystkich państwach. Przepisanie daty z jednego systemu do drugiego bez oznaczenia konwencji zmienia dzień używany przez efemerydę.

W raporcie warto zachować oryginalny zapis i dodać datę przeliczoną. Sam dzień juliański używany w obliczeniach nie informuje, jak źródło historyczne nazywało ten dzień.

Ograniczenie obecnego kalkulatora Afterlogy

Test wykazał, że obecny silnik Afterlogy nie sygnalizuje ani nieistniejącej godziny wiosennej, ani podwójnej godziny jesiennej dla Warszawy w 2026 r. Zwraca wynik według zachowania biblioteki, bez wyjaśnienia użytkownikowi, którą interpretację zastosował.

Dlatego przy dacie bliskiej zmianie czasu należy niezależnie sprawdzić strefę. Wyniku nie wolno przedstawiać jako jednoznacznego, jeśli lokalny zapis wpada w lukę lub powtórzenie. Jest to ograniczenie interfejsu i walidacji, nie dowód błędu Swiss Ephemeris, która otrzymuje już przeliczoną chwilę.

Procedura dla czasu granicznego

1. Zachowaj oryginalną datę, godzinę i miejsce.
2. Sprawdź regułę strefy dla tej daty w wersjonowanym źródle.
3. Ustal, czy godzina istnieje i czy jest jednoznaczna.
4. Przy powtórzeniu policz oba warianty UTC.
5. Przy luce wróć do źródła, zamiast arbitralnie przesuwać czas.
6. Zapisz identyfikator strefy, wersję tzdb, offset i UTC.
7. Dla dawnej daty podaj także konwencję kalendarza.

Wpływ niepewnej chwili na osie i domy omawia Kosmogram bez dokładnej godziny urodzenia.

Bibliografia

• IANA, Time Zone Database 2026d. Strona projektu (dostęp: 24.09.2026).
• IANA, Theory and pragmatics of the tz code and data, identyfikatory, skróty i ograniczenia historyczne. Dokumentacja (dostęp: 24.09.2026).
• U.S. Naval Observatory, Explanatory Supplement to the Astronomical Almanac, część dotycząca kalendarzy. Wydanie online (dostęp: 24.09.2026).
• Jean Meeus, Astronomical Algorithms, wyd. 2, Willmann-Bell 1998, rozdziały o datach i dniu juliańskim.
• Afterlogy, testy zachowania silnika dla luki i powtórzenia godziny w Europe/Warsaw, wykonane 24.09.2026.