36 багов 29 февраля 2024

[Fangaro]

Выключение освещения в Париже из-за программной ошибки и то, что потребовалось несколько часов на ручное включение... Для меня это удивительно, т.к. считал переход на управление от автоматики к оператору быстрым.

[GDragon]

Пока нашли инструкцию, пока откопали пульт, пока переключили...
Такое случается если система годами работает нормально в авторежиме.

А ещё если регулярные учения не проводятся, зачастую бывает что ручное управление уже сломано/завандалено/разобрано "по ненадобности".

[Dikiy_Koshmarik]

Интересно, что было в 2020-м году. Или перешли на новое ПО в 2021

[kovserg]

[Indemsys]

Добавьте 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);
}

[indrej]

Жесть какая. Должна быть всегда какая-то функция или класс для действий с датами, желательно низкоуровневая, с проведёнными юнит-тестами. И чтобы все знали, что она работает корректно. И весь код и приложения тупо работали с этой функцией, а не писали date-365. Вроде, все это знают. Но баги репортят даже в часах, где работа со временем - их профессиональная сфера. Вообще непонятно, откуда такие баги в принципе могут появиться.