Doba z 23 albo 25 godzinami: mały szczegół, duży błąd w analizie energii

Jednakowy napis nie oznacza jednakowego momentu

Lokalna godzina zapisana bez daty i przesunięcia względem UTC może być niejednoznaczna. Podczas jesiennego cofnięcia zegara dwa różne okresy mogą otrzymać podobną etykietę godziny. Jeśli arkusz połączy je w jeden wiersz tylko dlatego, że napis wygląda identycznie, część danych zniknie lub zostanie nadpisana.

Bezpieczny identyfikator okresu powinien zachowywać początek i koniec z jednoznaczną informacją o strefie. Własne zestawienie można prezentować w czasie lokalnym dla wygody, ale źródłowy znacznik czasu warto pozostawić w osobnej kolumnie. Dzięki temu łatwiej wyjaśnić ewentualną rozbieżność między systemami.

Ile punktów może mieć poprawna doba

W przypadku ciągłego szeregu godzinowego lokalna doba zmiany czasu może obejmować 23 lub 25 godzin. Przy okresach piętnastominutowych odpowiada temu odpowiednio 92 albo 100 przedziałów. Nie oznacza to samo w sobie braków lub nadmiaru informacji. Najpierw trzeba ustalić, jaką dobę i jaką strefę opisuje zbiór.

Przykład kontroli jest prosty: porównaj sumę długości przedziałów z rzeczywistą długością analizowanej doby. Nie dopisuj brakującego wiersza zerową ceną i nie usuwaj nadmiarowego rekordu wyłącznie po to, by uzyskać estetyczne 24 pozycje. Takie kosmetyczne wyrównanie zmienia wynik analizy.

Jak powstaje błąd kosztu

Załóżmy, że w powtórzonej godzinie mamy dwa różne okresy poboru: 1 kWh i 2 kWh. Ich ceny mogą być odmienne. Jeśli zachowamy tylko jeden zapis, zgubimy zarówno część energii, jak i właściwy koszt. Jeżeli bez rozróżnienia zsumujemy energię i użyjemy jednej ceny, również możemy uzyskać błędny wynik.

Modelowy problem nie ogranicza się do rachunków. Dotyczy też wyszukiwania najtańszych ciągłych okien, porównywania profili oraz statystyk godzin ujemnych. Z tego powodu w dokładnych analizach ciągłość czasu jest ważniejsza niż kolejność samych napisów od 00 do 23.

Krótka procedura porządkowania danych

Zachowaj oryginalny eksport, sprawdź jego strefę i nie zmieniaj źródłowych znaczników. Dopiero w kopii roboczej dodaj czytelną datę lokalną. Dopasowując ceny do pomiarów, łącz wiersze po jednoznacznym przedziale, a nie tylko numerze godziny. Kontroluj także, czy jeden system oznacza początek, a drugi koniec okresu.

Gdy widok aplikacji lub eksport wydaje się nietypowy, najpierw zapytaj o sposób prezentacji czasu. To lepszy pierwszy krok niż wniosek o błędnych notowaniach. Poprawna interpretacja dnia zmiany czasu jest jednorazowym wysiłkiem, który chroni cały późniejszy model przed trudnymi do zauważenia przesunięciami danych.

Przed wysłaniem zestawienia innej osobie dodaj krótką notę o zastosowanej strefie. Pozwoli to porównać wynik bez zgadywania, czy godzina została zapisana lokalnie, czy według czasu używanego przez źródłowy system.