Статия
Unix времеви отпечатъци и cron изрази
Unix времевият отпечатък е просто цяло число. Cron изразът е просто пет полета. И двете се срещат постоянно в бекенд работата и и двете подвеждат хората по предвидими начини: единият заради часовите зони, другият заради единицата.
Какво е Unix времеви отпечатък
Unix времевият отпечатък брои броя секунди, изминали от 1970-01-01 00:00:00 UTC, референтна точка, известна като Unix epoch. Тази дефиниция има две важни последствия. Първо, броенето е в UTC: в самото число няма вградена часова зона. 1718400000 означава един и същ момент навсякъде по Земята, независимо където се намират машините, съхраняващи го. Второ, epoch-ът е дефиниран в секунди, а не в друга единица. Стойност като 1718400000 винаги са секунди от полунощ 1 януари 1970 UTC, освен ако система или протокол не е направил изрично различен избор. Времевите отпечатъци са проектирани без часова зона, именно защото са полезни за логване, бази данни и комуникация между системи, при които часовниците в различни региони трябва да се отнасят към един и същ момент недвусмислено.
Секунди, милисекунди и проблемът от 2038 г.
Много съвременни среди за изпълнение и API използват милисекунди вместо секунди. Date.now() на JavaScript връща милисекунди, така че 1718400000000 е един и същ момент като стойността с прецизност до секунди 1718400000. Когато получите непознат времеви отпечатък, мащабът ви казва единицата: 10-цифрено число е почти винаги секунди; 13-цифрено число е почти винаги милисекунди. Проблемът от 2038 г. произтича от различен избор: съхраняване на времеви отпечатък с точност до секунди в знаков 32-битов целочислен тип. Максималната стойност на знаков 32-битов целочислен тип е 2147483647, което съответства на 2038-01-19 03:14:07 UTC. След тази секунда броячът препълва до голямо отрицателно число и датата се връща на 1901 при системи, неработещи с границата. Поправката е да се използва 64-битово съхранение. Повечето съвременни операционни системи и бази данни вече го правят, но вградените системи, мрежовите устройства и стари файлови формати, фиксирали ширината на полето преди десетилетия, остават изложени на риск.
Конвертиране на epoch към човешка дата: стъпката с часовата зона
Конвертирането на epoch стойност към четима дата изисква две стъпки: извличане на UTC компонентите на датата от целото число, след което прилагане на UTC отместване за получаване на местното часово. Самият времеви отпечатък е UTC. Когато попитате каква дата представлява 1718325000, правилният отговор е 2024-06-14 в 00:30 UTC. В Ню Йорк (UTC-4 лятно), същата секунда попада на 2024-06-13 в 20:30 предишната вечер: датата се сменя, не само часът. Това е стъпката, пропускането на която дава грешни резултати: разработчик записва суровия времеви отпечатък в UTC, инструментът за отчети го показва в местно часово без конвертиране и датата изглежда грешна с часове или цял ден. Инструментът за конвертиране на времеви отпечатъци на Sunasty обработва това изрично: въвеждате epoch стойност и той показва UTC датата и часа до собствената местна дата и час на устройството ви, така че пресичане на границата на деня като това е видимо на пръв поглед. Конвертирането работи изцяло в браузъра и нищо от поставеното от вас не се изпраща никъде.
Cron синтаксис: пет полета, диапазони, стъпки и списъци
Cron изразът планира повтарящи се задачи при Unix-подобни системи. Стандартният синтаксис има пет полета, разделени с интервал: минута (0-59), час (0-23), ден от месеца (1-31), месец (1-12), ден от седмицата (0-7, където и 0, и 7 представляват неделя). Звездичка (*) в поле означава „всяка валидна стойност”. Изразът 30 8 * * 1-5 се изпълнява в 08:30 от понеделник до петък. Диапазоните използват тире: 1-5 покрива стойности 1, 2, 3, 4, 5. Списъците използват запетаи: 1,15 означава 1-во и 15-о. Стъпките използват наклонена черта: */15 в полето за минути означава всеки 15 минути (0, 15, 30, 45). Тези комбинатори могат да се появяват заедно: 0-30/10 означава 0, 10, 20, 30. Cron няма поле за часова зона. Демонът чете часовника на машината, на която работи, настроен на местната часова зона на сървъра. Ако сървърът работи на UTC, но разработчикът очаква местно часово, задачата се изпълнява в грешния час. Практическото правило е да третирате cron разписанията като изрази за местното часово на сървъра и да документирате часовата зона на сървъра заедно с реда cron.
Използване на конвертора за времеви отпечатъци локално
Конверторът за времеви отпечатъци на Sunasty конвертира в двете посоки: от epoch към човешка дата и от човешка дата обратно към epoch. Можете да въведете стойност с точност до секунди или с точност до милисекунди; инструментът открива единицата по мащаба. Той показва резултата в UTC и в собствената местна часова зона на устройството ви едно до друго, заедно със суровите стойности в секунди и милисекунди, готови за копиране. Бутон „Сега“ попълва текущия времеви отпечатък с едно щракване, което е бърз начин да проверите текущото Unix време без да отваряте терминал. Няма отделен избирач на часова зона: локалната колона винаги отразява каквато и часова зона да е зададена в момента във вашия браузър. Всичко това работи в браузъра. Стойността, поставена в полето, се чете от JavaScript на страната на клиента и никога не напуска устройството.
Инструменти от тази статия
- Конвертор на времеви печатиКонвертирайте Unix epoch времеви печати към четими за хора дати (UTC + локални) и обратно. Автоматично разпознаване на секунди срещу милисекунди.
- Разлика в датиПреброй дните, седмиците, месеците и годините между две дати, изцяло в браузъра ти, нищо не се качва.
- Парсър за cron изразиРазбери cron израз и прегледай следващите му изпълнения. Поверително, в браузъра.
Често задавани въпроси
Защо JavaScript използва милисекунди вместо секунди?
Обектът Date на JavaScript е проектиран да работи с под-секундна прецизност от самото начало, а милисекундите дават хиляда пъти по-голяма разделителна способност от секундите, без да изискват десетична запетая. Компромисът е по-голям размер на стойностите, поради което Date.now() произвежда 13-цифрено число, докато повечето времеви отпечатъци от страна на сървъра са 10 цифри.
Трябва ли всеки сървър, изпълняващ cron, да е на UTC?
Не, но изпълнението на сървъри на UTC е обичайна практика именно защото премахва двусмислието. Когато сървърът е на UTC, cron израз като 0 2 * * * означава 02:00 UTC и това часово е стабилно през цялата година. На сървър в зона, спазваща лятно часово, същата задача се изпълнява в различен UTC момент лятото и зимата и може да се изпълни двойно или да се пропусне при смяната на часовника.
Какъв е безопасният тип съхранение за времеви отпечатъци след 2038 г.?
Знаков 64-битов целочислен тип съхранява времеви отпечатъци с точност до секунди до годината 292277026596, което е далеч извън всяко практическо безпокойство. Повечето съвременни бази данни съхраняват времевите отпечатъци като 64-битови стойности по подразбиране. Ако работите с наследна схема или двоичен файлов формат, използващ 32-битови полета, мигрирането към 64-битово съхранение преди границата 2038 е правилното решение.