Дни недели и месяцы: форматирование вывода

Расписание полива печатало в журнал день недели цифрой — 0, 1, 2 — и через месяц чтение лога превратилось в работу с календарём на коленке: какая это была среда, что за единица. Я завёл массив имён и тут же поймал классику: в бумажных заметках мои дни шли с понедельника, в массиве — с воскресенья, и после «исправления» лог стал врать ровно на один день. Поливалка честно докладывала «суббота» в пятницу, и я неделю искал несуществующую погрешность часов; журнал при этом выглядел безупречно — ровные колонки, стабильный формат, врал один словарь имён. С тех пор у меня правило: нумерация дня недели — свойство библиотеки, а не истина, и калибруется она по дате, которую вы точно знаете.

В этом уроке достанем из dayOfTheWeek() русские понедельник-вторник-среду, соберём месяцы в родительном падеже для красивой даты «16 сентября 2026», разберёмся с ведущими нулями и соберём три формата вывода — от сортируемого машинного до человеческого — без единой дополнительной библиотеки.

У той истории был и второй акт, не про журнал. Я вынес день недели на экран прибора цифрой — просто «3» — и вскоре услышал вопрос, который запомнил на годы: «а третий день — это что?» Число удобно машине: с ним сравниваются, по нему строятся расписания — вся сила числовых полей, о которой говорил урок про часы DS3231. Но человек читает слова, и между этими двумя языками стоит ровно один массив строк — собственно, вся тема этого урока.

Метод dayOfTheWeek() возвращает число от 0 до 6, но не хранит его в чипе: библиотека вычисляет день из календарной даты по григорианскому календарю — DS3231 про недели вообще не знает; седьмой геттер DateTime — тот же, что разбирался в уроке про разбор объекта. На настоящей плате в RTClib нумерация такая: 0 — воскресенье, 1 — понедельник, 6 — суббота. В симуляторе движок нумерует по другой привычке — с понедельника: 0 — понедельник, 6 — воскресенье. Оба варианта законны, они просто разные, и это лучшая иллюстрация главного правила: не верить памяти, калибровать по дате.

Пример калибровки в числах: 1 января 2025 года — среда. На плате RTClib вернёт для неё тройку (Вс=0, Пн=1, Вт=2, Ср=3), симулятор движка — двойку, потому что нумерует с понедельника. Если ваша таблица даёт другие числа — она врёт, и лучше увидеть это на известной дате при сборке, чем в журнале через месяц. Порядок имён внутри массива важнее самих имён: латиница или русский — вопрос монитора, а вот сдвиг на день — вопрос чести расписания. Проверка стоит одну строку в setup(): напечатали день недели для даты, которую помните, сверили — и можно спать спокойно.

Массив имён обязан идти в порядке нумерации метода, а не в порядке вашего любимчика. На плате это const char* DAYS[7] с воскресеньем первым; в симуляторе — с понедельником. Грабля усугубляется тем, что смещённый массив не роняет программу: строки просто сдвигаются на день, и программа работает год, пока кто-нибудь не сверит с настенным календарём — как моя поливалка, неделю рапортовавшая «субботу» в пятницу.

Месяцы устроены так же, но с лингвистическим нюансом. Для строки «16 сентября 2026» нужен родительный падеж: массив из двенадцати строк «января, февраля, марта…» по индексу month() минус один — месяцы в RTClib идут от единицы, а индексы массива от нуля, и это смещение — вторая по популярности калибровочная грабля после дней недели. Английские имена в этой ловушке не тонут — «1 May» звучит терпимо в обоих падежах, — а русские просят точности: «1 май» режет ухо, нужен именно родительный.

Ведущие нули — третий слой того же ремесла. Без них 9:05 выглядит как 9:5, а «1.2.26» двусмысленно до отвращения. Решение — крошечная функция two(): если число меньше десяти, сначала печатаем символ нуля, потом само значение; в скетчах она у меня переезжает из проекта в проект без изменений: два вызова two() заменяют четыре строки if в каждом месте вывода. Отдельный вопрос — год: now.year() % 100 даёт две последние цифры для коротких меток, но в журналах я печатаю год целиком: две цифры старятся, а четыре стоят те же символы, пока не сменился экран.

Красивая дата собирается склейкой, и здесь мой совет — не собирать её вообще. Печать кусками через несколько Serial.print() не создаёт временных строк и не тратит ОЗУ: печать раз в секунду на Uno живёт спокойно, а вот сборка длинной String на каждой итерации при частом цикле уже заметна. Проводить форматирование строками стоит только когда строку надо куда-то передать целиком — на экран, в файл; для монитора кусочков хватает. Паттерн «массив как таблица имён» вообще один из самых ходовых: он же работает в журналах и меню, как разобрано в уроке про массивы для журналов.

Формат стоит выбирать по потреблению, а не по вкусу. Машинный ISO 8601 — год, месяц, день с ведущими нулями: 2026-09-16 22:31:05. Его главный талант — сортировка: строки в таком виде сортируются по времени как обычный текст, потому что старшие разряды идут первыми. Для журналов на карте и логов в мониторе это единственный формат, который я использую; дата 16.09.2026 при строковой сортировке перепутает сентябрь с декабрём, потому что «09» больше «12» лишь в человеческой голове.

Человеческий формат — «среда, 16 сентября 2026, 22:31» — для дисплеев и отчётов: слово дня недели читается без календаря, месяц в родительном падеже звучит по-русски. Короткий формат — 16.09.26 22:31 — для беглых строк статуса, где дорог каждый символ: на LCD 16x2 в одну строку помещается ровно шестнадцать знаков, и короткий формат влезает вместе с данными, а длинный нет. Отдельный вопрос — двенадцатичасовой формат с PM: он стоит трёх строк кода (час больше двенадцати — минус двенадцать и литерал PM), но в русских интерфейсах почти не нужен; я печатаю 24-часовой всегда. Все три формата собираются из одного снимка now за одно проходжение loop(): геттеры вызываются один раз в переменные, дальше три ветки печати — и ни одна не пересекается с логикой будильника, которую мы строили в уроке про часы с будильником. Переключение формата в живом приборе — та же механика, что в симуляторе ниже: переменная fmt живёт глобально и переживает циклы, а перебирают её кнопкой меню или командой из монитора. Хранить формат в EEPROM — моё правило: прибор, который после включения показывает не тот формат, что вчера, выглядит сломанным, хотя код просто забыл состояние. А если у вашего монитора ещё не настроено окно, загляните в урок про первый запуск Serial-монитора: красивая дата и кракозябры легко путаются на глазах новичка.

Теперь момент времени одинаково понятен и машине, и человеку: числа для арифметики, красивая строка для экрана. Дальше по разделу — тревожная электроника модуля: будильники и таймеры самого DS3231, а до того стоит заглянуть в урок про точность и температурную компенсацию, чтобы понимать, откуда берётся та самая минута ухода в год, ради которой всё и затевалось. А массивы DAYS и MES из скетча забирайте в свои приборы целиком — они переживут и этот проект.