TimeSpan: длительности и арифметика времени

Настой удобрений для рассады держится тридцать шесть часов, карантин нового аквариума — две недели, проветривание погреба — четверть часа. В каждом случае я хочу одного: записать момент начала, узнать момент готовности и в любой день спросить «сколько осталось». Первую версию я написал по-наивному: хранил час готовности и прибавлял к часу длительность. Тридцать шесть часов поверх девяти вечера дали шестьдесят один час — а дальше скетч честно искал 61-й час суток, которого не бывает. Полночь, перенос на завтра, високосный февраль — каждый перенос надо бы дописывать руками, и каждый я когда-то обязательно забыл бы.

Всё это уже решено в библиотеке: у RTClib есть класс TimeSpan — длительность в четырёх числах, с которой момент складывается одной строкой, а полночь и месяцы проходят сами, потому что внутри это просто секунды. Разберу конструктор и методы, потом соберу обратный отсчёт с дедлайном, а заодно честно скажу, где TimeSpan заменяется простой unix-арифметикой — в том числе потому, что симулятор на этом сайте TimeSpan не эмулирует.

Полезно заранее разложить задачи арифметики времени на три сорта, потому что у них один инструмент, но разные вопросы. Сдвиг: к известному моменту прибавить длительность и получить дедлайн. Остаток: от дедлайна вычесть текущий момент и узнать, сколько осталось. Длительность: из двух отметок сделать интервал — сколько длилось проветривание или насос. TimeSpan закрывает все три, unix-секунды — тоже: выбор внутри урока будет не между «правильно и неправильно», а между «библиотечная запись» и «та же запись в четырёх делениях».

Конструктор принимает ровно четыре аргумента в порядке дни, часы, минуты, секунды: TimeSpan(1, 12, 0, 0) — это сутки и половина, те самые тридцать шесть часов. Порядок — самая частая оплошность новичка: хочется написать «часы, минуты, секунды», и TimeSpan(2, 0, 0) внезапно означает не два часа, а два дня. Я сам в первый раз получил сдвиг на два дня вместо двух часов и час искал, куда делись сутки, — с тех пор в спорных местах пишу все четыре аргумента с нулями: TimeSpan(0, 2, 0, 0).

Методы отдают компоненты: days(), hours(), minutes(), seconds(). Подвох в том, что это компоненты остатка, а не полные величины. Для тридцати шести часов days() вернёт 1, а hours() — 12, не 36: сутки уже забрал days(). Если вам нужны «итого часов», считайте самому: totalseconds() / 3600 — метод totalseconds() отдаёт всю длительность одним числом в секундах. Это же число — валюта для любых сравнений и накоплений: интервалы складываются и вычитаются в секундах без заботы о переносах.

Арифметика собирается из трёх операций. DateTime плюс TimeSpan даёт новый момент — так рождается дедлайн: DateTime deadline = now + TimeSpan(1, 12, 0, 0). Разность двух DateTime даёт TimeSpan — так рождается остаток: TimeSpan left = deadline - now. А TimeSpan складывается с TimeSpan, когда длительности копятся. Всё это честно переходит через полночь, конец месяца и февраль: тридцать шестой час сам найдёт следующие сутки, и писать переносы руками не нужно. В симуляторе на этом сайте TimeSpan не поддержан движком — поэтому здесь я делаю ту же арифметику через unixtime, а TimeSpan оставляю в код-блоках для платы.

В сим-скетче ту же службу несут секунды с 1970 года. Дедлайн — это unixtime начала плюс длительность в секундах: dedlain = t0 + 150. Остаток — вычитание: left = dedlain - t, где t — рабочее время. А разложение остатка на дни, часы, минуты и секунды — это деления с остатком, те самые, что я разбирал в уроке про массивы и журналы на примере перевода секунд: дни — это left / 86400, потом остаток делится на 3600, из него берётся минутная доля, и последнее деление отдаёт секунды. Цепочка на четыре строки заменяет весь API TimeSpan — и я честно пользуюсь ею на плате, когда TimeSpan под рукой не нужен. Для контроля возьмите 129600 секунд: делениями получится ровно 1 d 12 h — те же тридцать шесть часов, что в конструкторе TimeSpan(1, 12, 0, 0).

Разница между платой и симом остаётся прежней: на плате рабочее время даёт rtc.now() в каждом проходе loop(), а в симуляторе часы застывают на моменте запуска, поэтому скетч ведёт время от якоря t0 плюс millis()/1000 — паттерн настоящего класса RTC_Millis из той же библиотеки. Секунды при этом тикают по-настоящему: за счёт виртуального времени симулятора остаток падает на глазах. Фронт готовности считается флагом из урока про свет по расписанию: строка GOTOVO и гудок зуммера выходят один раз, а не каждые две секунды после дедлайна. И проверка ввода та же: parseInt() после available(), мусор отбрасывается — подробности в уроке про чтение чисел из монитора.

Три приёма из практики, которые ложатся поверх скетча. Первый — накопление наработки: сколько суммарно отработал насос за сезон. Каждое срабатывание добавляет в счётчик long длину интервала в секундах, печать — тем же разложением на дни и часы. Запас у знакового long огромный: два миллиарда секунд — это под семьдесят лет наработки, за которую вы этот счётчик пять раз перепрошьёте. Второй — сравнение выдержек между собой: «какой дедлайн ближе» — это обычное сравнение секунд, без календаря.

Третий приём самый ценный — он про то, что дедлайн может оказаться в прошлом ещё при старте. Пока плата была выключена, выдержка не остановилась: удобрение настоялось, карантин прошёл. Скетч с проверкой now < deadline при включении сразу увидит отрицательный остаток и сразу поднимет флаг готовности — и это правильное поведение, а не сбой: с дедлайном, сохранённым в EEPROM, отсчёт переживает выключение, а с переменной в ОЗУ — нет. Именно поэтому в проектах с выдержкой я пишу дедлайн в энергонезависимую память и после загрузки первым делом сравниваю его с текущим временем.

И последняя развилка, чтобы не изобретать велосипеды: интервалы короче нескольких минут я считаю millis()-таймерами из урока про millis() вместо delay() — они дешёвые и не требуют железа. Когда речь о часах и днях, millis() уже не спасает: плата не переживёт без сброса столько, а часы DS3231 — запросто. Граница в моём коде лежит примерно на паре часов: меньше — millis(), больше — RTC с TimeSpan или unix-арифметикой.

Теперь у расписания есть обе половины: окна по часам суток из первого урока и длительности со сдвигами из этого. Дальше по разделу эти же часы встают в более сложные приборы — будильник с LCD уже написан в соседнем уроке, а если часы захочется сверять по сети, то первый шаг — подключение ESP32 к Wi-Fi и NTP-сервер: unixtime оттуда и от DS3231 складываются в одну арифметику без переделок.