Już parę razy stosowałem w swoich projektach prosty RTC, zbudowany w oparciu o Timer2 i kwarc zegarkowy. Ponieważ nie było mi potrzebne wyświetlanie czasu w formie czytelnej dla człowieka, stosowałem Unix Timestamp (32 bitowa zmienna, licząca ilość sekund, jakie upłynęły od 1 stycznia 1970 roku). Niebywałą zaletą takiego rozwiązania jest łatwość synchronizacji za pomocą NTP oraz prosta obsługa samego zegara - wystarczy zwiększać zmienną o 1 w przerwaniu 1Hz.
Teraz jednak pojawiła się konieczność przetłumaczenia tej zmiennej na "ludzki" czas, uwzględniający strefę czasową, czas letni i zimowy, a także lata i sekundy przestępne. Odpowiednia funkcja będzie wykonywana tylko od czasu do czasu - użyję jej do oznaczania plików w FatFS oraz wyświetlania czasu na LCD/OLED (który jednak będzie aktywny tylko na żądanie). Z tego powodu nie opłaca mi się odchodzenie od czasu Uniksowego, na rzecz kaskady instrukcji warunkowych, wykonywanych w przerwaniu zegara.

W Linuksie dostępne są wygodne funkcje, konwertujące czas systemowy do formy struktury albo tekstu.
Czy ktoś zetknął się z podobnym, sprawdzonym kodem dla AVR, ewentualnie Arduino, który można by przeportować?

Hmm... Wykorzystałem jeszcze inny kod, wzorując się na zegarze ze strony Tuxgraphics.



Działa, jednak pokazuje czas spóźniony o dwie godziny. Podejrzewam wiec, że została w nim zakodowana na stałe inna strefa czasowa.
Co powinienem zmienić, żeby funkcja działała prawidłowo w polskich warunkach? Wiem, że mógłbym ręcznie dodawać te dwie godziny, ale przecież to nie załatwi sprawy zmiany czasu z letniego na zimowy i odwrotnie. Jak powinien wyglądać ko realizujący taką funkcjonalność.

I jeszcze odnośnie zmiany czasu. Jak to jest zwykle realizowane w datalogerach? W jakim formacie zapisuje się czas odczytu? Bo chyba nie w czasie lokalnym, w którym jedna godzina może wystąpić ponownie. UTC? A może wystarczy czas uniksowy?

W jaki sposób powinna być zrealizowana obsługa sekund przestępnych? A może są one uwzględniane już na poziomie systemu NTP?

Ja teorię mniej-więcej znam...
Chodzi mi raczej o przykład praktycznej implementacji algorytmu, który robiłby to wszystko w sposób zautomatyzowany. Parę pomysłów mam, nie wiem jednak, czy są one najbardziej optymalnymi rozwiązaniami.

Na chwilę obecną mam:
1) Synchronizację przez NTP
2) RTC zliczający sekundy w formacie uniksowym.
3) Procedurę konwertującą podany czas (Unix timestamp) do formy czytelnej dla człowieka i zapisującą go do struktury z rozbiciem na godziny, minuty, sekundy, dni itp.

Ten zestaw jest w tej chwili wykorzystywany do oznaczania pomiarów oraz modyfikacji plików (FatFS) za pomocą czasu UTC.

Mój pomysł na rozwiązanie jest następujący:

1) Dodać procedurę stwierdzającą na podstawie podanej daty i godziny, czy mamy do czynienia z czasem letnim, czy zimowym. Kilka przykładów jest w sieci.
2) Przy konwersji z unix timestamp do struktury podawać czas na zasadzie (timestamp + offset*ILOSC_SEKUND_NA_DZIEN), jeśli tylko chcemy uzyskać na wyjściu czas lokalny.
3) Cyklicznie wywoływać funkcję sprawdzającą, czy mamy do czynienia z czasem letnim czy zimowym. Wynik jej działania zapisywać w osobnej zmiennej globalnej uint8_t offset. W takim wypadku jak częste powinny być wywołania? Wystarczy przy każdej pełnej minucie czy może jeszcze rzadziej?

A może istnieje bardziej optymalny sposób? Może da się w jakiś sposób zorientować jaki mamy czas już podczas konwersji z czasu uniksowego do struktury?