Відповіді:
ring0 побив мене декількома секундами, але повна команда:
echo $(($(date --utc --date "$1" +%s)/86400))
Це йде за часом UTC. Результат:
root@hostname:~# echo $((`date --utc --date "$1" +%s`/86400))
14984
Швидка перевірка з WolframAlpha показує , що це правильне значення.
Я думаю, що це найпростіший метод:
expr $(date +%s) / 86400
Мені також потрібно було вирішити це, але я хотів отримати те саме значення для # дня, незалежно від часу доби. При таких підходах, як показано тут, значення буде змінюватися о півночі UTC, а не опівночі за місцевим часом. Це, мабуть, здається меншою проблемою в ЄС або на Східному узбережжі США, які досить близькі до UTC, щоб значення дня не змінилося в середині типового робочого дня, але, наприклад, у Каліфорнії, день змінився відбудеться о 16:00 PST, що може бути незручно. Я думаю, австралійцям було б особливо прикро, що пізній ранок змінить значення дня.
Якщо ми хочемо виправити це, нам потрібно додати зміщення від UTC перед діленням на сек / день. На щастя, команда дати Linux включає послідовність формату % z , яка повідомляє про зміщення від UTC. Хоча стандартний формат (цей результат призначений для Денверського часу, MDT):
$ date +%z
-0600
. . . Не підлягає прямому використанню в розрахунку, правильні модифікатори дадуть те, що ми хочемо:
$ date +%-:::z
-6
Поставте це разом із звичайними перетвореннями сек / годин / днів, і я вважаю, що наступні повинні виводити дні з 1.01.1970 року, при цьому сам 1/1/1970 день дорівнює нулю, а значення збільшується опівночі за місцевим часом:
echo $(( ( $(date +"%s + ( %-:::z * 3600)") ) / 86400 ))
Цей простий обчислення не буде працювати для часових поясів, які не зміщені від UTC на цілі години (наприклад, Індія, TZ = Азія / Колката), оскільки "+5: 30", вироблений, date +%-:::z
призведе до помилки "недійсний символ у виразі" при використанні у наведеному вище твердженні.
$()
перевага віддається перед задніми мітками з читабельності та інших причин .echo $(( $(date ...) / 86400 ))