В очередной раз подтверждаю - проверять все и проверять чужое!
В нескольких сотнях серийно выпущенных устройств с 1 февраля этого года часы идут на сутки раньше.
Т.е. задаешь дату например 19 фев, а возвращает 18.
Библиотечка с сайта st.
Там функции конверсии структуры даты в long int и назад:
Для дат 1.февраля и 31 января 2013 года одинаковое значение long int t = 412966800 влип!

tt.year = 13;
tt.month = 2;
tt.mday = 01;
//tt.wday=
tt.hour = 17;
tt.min = 00;
tt.sec = 00;

t = rtc_struct_to_cnt( &tt );
rtc_cnt_to_struct( t, &tt );

printf("t=%u\r\n", t);
printf("%2u/%02u/%02u %2u:%02u:%02u\r\n", tt.mday, tt.month, tt.year, tt.hour, tt.min, tt.sec);

Кто еще налетел?
Кто уже нашел? Сижу ищу.
Прилагаю исходники.

Вам надо бы уточнить, что это для STM32F1xx...

Там вообще нечего заимствовать. Посмотрел f1 и f2/4, становится совершенно понятно, что f1 rtc просто никакие. А библиотека под них затачивалась. А для f4 уже допиливалась. И общая картина катастрофическая .... Не так, не там, не то ...
Я изначально переписал с нуля. Писал для f4. А потом лучше f1 допилю под эту.
Часы у четвёрки нормально сделаны.

Либо я что-то не понимаю, либо... А зачем вообще нужны функции конверсии времени в Сях, где есть штатные gmtime() / localtime() ?
Кроме переопределения time() на собственную элементарную имплементацию, вообще никаких забот. Или я что-то все же упустил?

Скорее всего для сравнения.
Ну например вы работаете с архивами. У вас запрос "найти запись со временем раньше чем ...", ну и так далее... И всё на этом построено. Сравнивать лесенкой годы, месяцы и так далее ... длительный процесс. А если у вас такого по программе куча?
Вот тогда приводят всё, например к секундам относительно 1.1.2000. И время хнанят в таком виде. А сравнение - одно сравнение.

Вот, именно это и называется time_t (только с 1970 года), и именно с таким временем работают функции из <time.h>.

Ну да. Только с точностью до наоборот - изначально время только в таком виде. А всё остальное, в частности конверсии - просто нахлобучки сверху, для удобства. Но мой вопрос был в другом - при наличии стандартной "нахлобучки", в виде gmtime() / localtime(), зачем изобретать велосипед?

Стандарт говорит, что

Однако тут сказано, что "почти всегда" это число секунд с начала 1970 года. Для пущей уверенности можно вставить в программу assert() на это дело, чтобы при переходе на другую библиотеку не получился сюрприз.

А проверять действительно надо! Особенно когда сторонние библиотеки используются.
Вчера столкнулся - делаю прогу, все норомально. Добавляю функции UART, путем подключения модуля с другой программы, где все работало, меняю UART3 на UART2 ну и ноэки куда оно подключено - нифига не работает.
Я тихо фигею, смотрю отладчиком - нет TXE. Потом гляжу - что-то регистр битрейта какой-то очень странный. Устанавливал я его при ините уарта, библиотечной функцией.
Плюю на библиотеку, ставлю руками наобум число - все работает.
Что оказалось - виноват был расчет регистра битрейта в STшной библиотеке - в предыдушем девайсе был сначала HSE=24Mhz, потом 25Mhz, и все было ОК. А в новом девайсе уже HSE_VAL=24.5MHz и библиотека обломалась на некруглом числе.

Тоже такая ситуация, у меня часы с жпс, проц f100, ежедневная синхронизация в 6 утра. Глюк с запаздыванием даты был замечен 10 февраля, но он может был и раньше.
По этой теме понял что есть проблема, попробую сегодня разобраться.

Значит методом тыка было замечено , что проблема именно 2 месяца, 13..14..15 года. Можно переждать этот месяц)))

Проблема возникает когда в феврале 28 дней


Наверно это чисто моя проблема и к топик-стартеру не относится. Выявил компенсацию не понятную мне, но после ее отмены все кодируется и декодируется нормально. Проверял 2016 годом где в феврале 29 дней, переходит нормально, ну и где 28 дней тоже.

Компенсация-то понятная - чуть выше мы складываем число дней во всех месяцах меньше текущего, и в массиве числа дней для февраля значится 29. Следовательно, если год не високосный, то надо вычесть один день. А бага простая - мы начинаем вычитать день не с марта, а уже с февраля, хотя тот самый 29-й день еще не наступил.

Исправить багу просто:


Кстати, небольшой оффтопик: лично мне кажется, что часы в F2/F4 сильно испортили по сравнению с F1.
В F1 время хранилось в виде числа секунд, и совершенно простейшим образом тикало, сравнивалось, складывалось и вычиталось.
И можно было в низкоуровневом коде вообще забить на все часовые пояса, летнее/зимнее время, leap seconds и все такое прочее, а вводить эти сложности уже на самом верхнем уровне, непосредственно при печати времени для человека, где и думать, в каком виде человек хочет это время увидеть.
В F4 же теперь приходится хранить в человекочитаемом виде, а для всех операций конвертировать в нормальное 32-битное.
Опять же, например, я совершенно не верю ST-шной железной реализации правильных коррекций времени. Ну вот ни на грамм не верю, что они в момент June 30, 2012 23:59:60 UTC выдавали правильное время, а не на секунду позже, 1 июля 00:00:00 А иногда это важно.

+1. Я тоже был опечален этими изменениями.

А не могли бы Вы поделиться библиотекой? Мне просто в девайсе на ф4 тоже часы нужны