Я обнаружил некоторые дополнительные ограничения вышеуказанных подходов, которые могут не работать в некоторых крайних случаях. Например, рассмотрим:
@ xahtep и @Doppelganger обсуждали проблемы, используя %W на определенных границах года выше.
@ ответ Пилкроу до некоторой степени обходит это, однако он также потерпит неудачу на определенных границах. В ответах в этой и других смежных темах используется количество секунд в дне (по сравнению с неделей), которое также не выполняется на определенных границах по тем же причинам.
Это потому, что эти подходы основаны на времени UTC (дата +% s). Рассмотрим случай, когда мы выполняем работу в 1:00 и 22:00 каждый второй вторник.
Предположим, GMT-2:
- 1:00 по местному времени = 23:00 UTC вчера
- 22:00 по местному времени = 20:00 UTC сегодня
Если мы проверяем только один раз каждый день, это не будет проблемой, но если мы проверяем несколько раз - или если мы приближаемся к времени UTC и происходит переход на летнее время, скрипт не будет учитывать эти быть в тот же день.
Чтобы обойти это, нам нужно рассчитать смещение от UTC на основе нашего местного часового пояса, а не UTC. Я не смог найти простой способ сделать это в BASH, поэтому я разработал решение, которое использует быструю однострочную в Perl для вычисления смещения от UTC в считанные секунды.
Этот скрипт использует дату +% z, которая выводит местный часовой пояс.
Bash скрипт:
TZ_OFFSET=$( date +%z | perl -ne '$_ =~ /([+-])(\d{2})(\d{2})/; print eval($1."60**2") * ($2 + $3/60);' )
DAY_PARITY=$(( ( `date +%s` + ${TZ_OFFSET} ) / 86400 % 2 ))
затем, чтобы определить, является ли день четным или нечетным:
if [ ${DAY_PARITY} -eq 1 ]; then
...
else
...
fi