Profesjonalny serwer na OVH
Za pomocą polecenia date(’Z’) i date(’I’) uzyskałem kolumny Tzone oraz Letni.
Rekordy wprowadzane co 5 minut mają przerwę między 2:00 a 3:00, kiedy nastąpiło wiosenne przesunięcie zegara.
Zmiana czasu w odniesieniu do baz danych zawierających sekwencje pomiarów jest niemałym wyzwaniem myślowym bo o ile wiosną nie stracimy pomiarów to już jesienią, kiedy cofniemy wskazówki z 3:00 na 2:00 to stracimy cenne skrupulatnie zbierane rekordy danych.
jesienne cofanie
Jesienny powrót do czasu UTC+01:00 w bazie na serwerach OVH
Przy jesiennej zmianie czasu 26X2025 wykres wykonany za pomocą HighChart jest godny analizy. Nie wnikając jakie otrzymał dane to oś odciętych jest zadziwiająca: godziny od 2:00 do 2:00 (3:00) występują podwójnie!
Prezentacja danych zebranych w noc zmiany czasu międzu godziną 2:00 a 3:00 czasu letniego jest dość karkołomna ale jak widać HighChart sobie nieźle radzi. PKP niestety nie – bo zatrzymywanie pociągów o 2:00 w nocy jest nieakceptowalne z punktu widzenia pasażera jakim nie raz byłem.
Amatorskie rozwiązania QNAP i unRaid
Wiosną 2025 te serwery nic nie zmieniały. Czas jaki podał PHP został zapisany w bazie i między drugą a trzecią wszystko zapisywało się po staremu. unRaid obsługuje kontener z bazą:
niestety polecenia date(’Z’) i date(’I’) zwracają zero więc nie informują ani o strefie czasowej ani o zmianie czasu letni/zimowy
Podobnie QNAP wymaga własnych ręcznych rozwiązań przy zmianie czasu.
Jesienna zmiana
Przy jesiennej zmianie czasu 26X2025 wykres wykonany za pomocą HighCharts na osi X zdublował godzinę 1:00 ale nie zgubił pomiarów wykonywanych w „cofniętej” godzinie.
Pomiary można uśredniać, interpolować i ekstrapolować natomiast systemy monitoringu nie mogą „gubić” rejestracji. Ciekawe jak pokazują te z czasu między 2:00 a 3:00 czy pytają o czas letni i zimowy ?