Comments 6
Выключение освещения в Париже из-за программной ошибки и то, что потребовалось несколько часов на ручное включение... Для меня это удивительно, т.к. считал переход на управление от автоматики к оператору быстрым.
Пока нашли инструкцию, пока откопали пульт, пока переключили...
Такое случается если система годами работает нормально в авторежиме.
А ещё если регулярные учения не проводятся, зачастую бывает что ручное управление уже сломано/завандалено/разобрано "по ненадобности".
Интересно, что было в 2020-м году. Или перешли на новое ПО в 2021
Добавьте 37 баг.
В компиляторе IAR for ARM функция mktime до сих пор не учитывает високосный год и при преобразовании секунд от серверов точного времени выдаст вместо дня 29 февраля день 1 марта :
typedef struct tm rtc_time_t;
void Convert_NTP_to_UTC_time(ULONG seconds, rtc_time_t *p_rt_time, int32_t utc_offset)
{
seconds = seconds - 2208988800;
p_rt_time->tm_sec = seconds;
p_rt_time->tm_min = 0;
p_rt_time->tm_hour = utc_offset;
p_rt_time->tm_mday = 0;
p_rt_time->tm_mon = 0;
p_rt_time->tm_year = 0;
p_rt_time->tm_wday = 0;
p_rt_time->tm_yday = 0;
p_rt_time->tm_isdst = 1;
mktime(p_rt_time);
}
Жесть какая. Должна быть всегда какая-то функция или класс для действий с датами, желательно низкоуровневая, с проведёнными юнит-тестами. И чтобы все знали, что она работает корректно. И весь код и приложения тупо работали с этой функцией, а не писали date-365. Вроде, все это знают. Но баги репортят даже в часах, где работа со временем - их профессиональная сфера. Вообще непонятно, откуда такие баги в принципе могут появиться.
36 багов 29 февраля 2024