Конвертер времени меток UNIX: эпохи, часовые пояса и ошибка 57123 года

Пользователь одного из моих приложений Laravel SaaS однажды отправил по электронной почте дату продления его подписки, которая выглядела «немного щедрой». На странице выставления счетов сообщалось, что его план продлится 25 апреля года. 57123, йо-

Ошибка потребовала мне смущающе долгого поиска, потому что каждая отдельная часть была правильной. Отправленный интерфейс React Date.now()- который возвращается миллисекунды- и серверная часть PHP сделала это date('Y-m-d', $timestamp), что ожидает секунда, йо- кормить 1740470400000 в функцию, ожидающую 1740470400 И вы приземлитесь примерно 55 000 лет в будущем. Ни исключения, ни предупреждения, ни неудачного теста. Просто клиент вежливо спрашивал, действительно ли его подписка продлилась до жары цивилизации.

Временные метки выглядят как самая скучная тема в программном обеспечении. На самом деле они являются одной из самых надежных фабрик, которые у нас есть: секунды против миллисекунд, UTC против локальных переходов DST, переворот 2038 года. выше Конвертер времени отметки времени на Toolz.dev существует потому, что я устал делать new Date(x * 1000) В браузере консоль сорок раз в день. Это руководство охватывает то, что я сейчас проверяю, в том порядке, в котором я проверяю.

TL;DR: Временная метка Unix считает секунды с 1970-01-01T00:00:00 UTC. 10 цифр = секунды, 13 цифр = миллисекунды- смешивая их, вы получаете скидку на 55 000 лет. Храните UTC, конвертируйте только для отображения, используйте названия зон IANA, например Asia/Dhaka вместо сокращений. Вставьте любую метку времени в Конвертер времени отметки времени чтобы получить формы ISO 8601, RFC 2822, локальные формы и формы UTC, он запускает клиентскую сторону, поэтому временные метки не выполняются ютс А производственные журналы никогда не покидают ваш браузер.

Что такое метка времени unix?

Временная метка UNIX (время эпохи, время POSIX) — это количество секунд, прошедших с момента 1 января 1970 г., 00:00:00 UTC- "Unix epoch." It's одно целое число, у него нет часового пояса (it's всегда UTC по определению), и фактически каждая ОС, язык и база данных понимают его. Это последнее свойство - вот почему он выдержал пять десятилетий: это формат одного раза, о котором никто не спорит.

Почему 1970? нет глубокой причины - это была удобная круглая дата вблизи, когда Unix строился в Bell Labs, и ранняя Unix считала время в 32-битном целом числе. произвольный выбор окаменел в универсальный стандарт, который очень Unix.

Некоторые ориентиры, которые стоит признать на месте:

Эта четвертая строка — мой любимый пример по тонкой причине: много страниц учебных страниц 1740470400 AS "25 февраля 2025 г., 12:00:00. 08:00 UTC- кто-то один раз преобразовал его в свой местный часовой пояс, и с тех пор копирование неправильного значения повесили. Проверяйте временные метки с помощью инструмента, а не с помощью сообщения в блоге. Включая этот.

Секунды или миллисекунды - как вы говорите?

Подсчитайте цифры. Для любой даты в текущую эпоху:

• 10 цифр (1740470400) - секунды. Соглашение Unix, большинство API, PHP и #39;s time(), Python's time.time() (как поплавок), API полосы.
• 13 цифр (1740470400000) - миллисекунды. JavaScript's Date.now(), Ява System.currentTimeMillis(), даты монгодб.

Это точное различие, которое привело к моей дате продления года 57123, поэтому я расшифрую режимы отказа:

• MS интерпретируется как секунды → даты ~ 55 000 лет в будущий
• секунд, интерпретируемые как MS → Даты в Январь 1970 г. (Все сворачивается в течение ~ 3 недель после начала)

Если вы видите либо подпись - древние даты, либо абсурдные даты далекого будущего - вы знаете ошибку перед чтением строки кода.The Конвертер времени отметки времени Обнаруживает количество цифр и маркирует обе интерпретации, что решает вопрос "это s или MS?"

Какие форматы дат вам действительно нужно знать?

Три охватывают почти все, к чему прикасается работающий разработчик.

ИСО 8601- международный стандарт и что вам следует указывать в API и журналах:

2026-07-13T09:30:45Z          UTC ("Z" = Zulu)
2026-07-13T15:30:45+06:00     with timezone offset
2026-07-13T09:30:45.123Z      with milliseconds

Функция убийцы никто не упоминает: струны ISO 8601 Сортировать лексикографически в хронологическом порядке, йо- sort В файле журнала просто работает. 02/25/2026-форматы стилей могут 't сделать это - и что еще хуже, США MM/DD и европейский DD/MM неразличимы в течение двенадцати дней каждого месяца.

RFC 3339 (специальный) - профиль интернет-протокола ISO 8601. Немного строже; если ваш API излучает 2026-07-13T09:30:45Z Вы удовлетворяете обоих. Это формат, который можно стандартизировать.

RFC 2822 (Sun, 13 Jul 2026 09:30:45 +0000) - заголовок электронной почты и HTTP, RSS-каналы. Вы читаете его чаще, чем пишете.

Форматы базы данных близки к сестринам: MySQL DATETIME есть 2026-07-13 09:30:45 (Iso с пробелом), PostgreSQL timestamptz риа 2026-07-13 09:30:45+00, йо-

Как языки, которые я использую, обрабатывают временные метки?

Три из моей стопки - и причуда в каждой, которая лично стоила мне времени.

Javascript (МС 1):

Math.floor(Date.now() / 1000)        // current Unix seconds — Date.now() is ms!
new Date(1740470400 * 1000)          // seconds → Date: multiply by 1000
date.toISOString()                   // "2025-02-25T08:00:00.000Z"
Date.parse('2026-07-13T09:30:45Z') / 1000   // ISO string → Unix seconds

причуда: все миллисекунды, и new Date(1740470400) Молчаливо выдает 21 января 1970 года вместо февраля 2025 года. Нет ошибки. Эта асимметрия является самой распространенной ошибкой метки времени в веб-разработке.

php (Секунды):

time();                                   // current Unix seconds
date('Y-m-d H:i:s', 1740470400);          // "2025-02-25 08:00:00" (server TZ!)
strtotime('2026-07-13 09:30:45');         // string → timestamp
(new DateTime('@1740470400'))
    ->setTimezone(new DateTimeZone('Asia/Dhaka'))
    ->format(DateTime::ATOM);             // "2025-02-25T14:00:00+06:00"

причуда: date() Форматы в сервер's Часовой пояс по умолчанию, поэтому один и тот же код печатает разные даты на вашем компьютере и в производстве. Кроме того, new DateTime('@1740470400') игнорирует любой часовой пояс, который вы передаете конструктору - the @ форма всегда UTC; вы должны позвонить setTimezone() после. WordPress добавляет свой собственный слой: current_time('timestamp') Возвращает фальшивое смещение времени "локального" смещение от реального времени Unix, которое так же опасно, как и звучало.

питон,

import time, datetime
int(time.time())                                      # current Unix seconds
datetime.datetime.fromtimestamp(1740470400,
    tz=datetime.timezone.utc)                         # → aware datetime
dt.isoformat()                                        # "2025-02-25T08:00:00+00:00"

причуда: fromtimestamp() без tz= Возвращает наивное время DateTime в местном времени. Наивные даты — это ошибка времени Python: они сравнивают и вычитают счастливо друг против друга, пока один из них не пересекает границу DST. Всегда проходить tz=; использовать zoneinfo (STDLIB с 3.9) для названных зон.

Как вы должны обращаться с часовыми поясами, не сводя с ума?

Четыре правила, все научились раздражающим способом:

1. Хранить UTC. всегда. unix timestamps или timestamptz в базе данных. Часовой пояс становится только проблемой дисплея.
2. Преобразование на уровне презентации. Пользователь в Дакке видит +06:00, пользователь в Берлине видит +02:00, база данных не видит ни того, ни другого.
3. Используйте имена IANA, а не аббревиатуры. Asia/Dhaka, America/New_York, Europe/Berlin. Сокращения неоднозначны - CST означает Центральное стандартное время США, Китая или стандартное время Кубы в зависимости от того, кто & # 39;s читает - и сокращения don & # 39;t кодируют правила летнего времени. Имена IANA делают.
4. Никогда не бросьте ручное DST-логику. Даты летних периодов различаются по странам, изменениям в соответствии с законодательством, а в некоторых местах (Аризона, Бангладеш, Япония) вообще не соблюдают летнее время. База данных IANA TZ существует, потому что это действительно сложно; используйте библиотеку, которая ее обертывает.

Следствие правила 1: когда две системы расходятся во мнениях относительно времени события, преобразуйте оба значения в UTC UNIX Timestamps и сравните целые числа. Споры о "Но тут написано 3 часа дня" растворяется мгновенно.

В чем проблема Y2038 и стоит ли вам небезразлична?

32-битное целое число с максимальной меткой 2,147,483,647, йо- В качестве временной метки Unix это 19 января 2038, 03:14:07 UTC. Через секунду значение становится отрицательным - до 13 декабря 1901 года.

Звучит далеко; это 't, по двум причинам. Во-первых, это 's примерно через 11,5 лет, пока я пишу это - значительно в течение срока службы встроенных систем, промышленных контроллеров и той одной устаревшей службы, к которой никто не хочет прикасаться. Во-вторых, будущий Даты рано на стену: система, которая вычисляет 15-летний график ипотеки или 20-летний срок действия сертификата, 2038 сегодня, йо- MySQL's TIMESTAMP тип столбца - это классическая ловушка: 32-битная и can't хранят даты после 19 января 2038 г., а DATETIME В той же базе данных все в порядке.

Вы в безопасности на 64-битном time_t (любая современная ОС), JavaScript (FLOAT64 MS), Python (произвольная точность) и PostgreSQL. Вы в опасности на 32-битных встроенных системах, старых TIMESTAMP Столбцы и код C, которые жестко закодированы int32_t на время. Тест прост: толкать 2147483648 (одно превышение предела) через ваш конвейер и посмотрите, что выйдет. выше Конвертер времени отметки времени С радостью сгенерирует ваши тестовые значения после 2038 года.

Где метки времени появляются в реальной отладке?

Срок действия JWT. токены несут iat а exp Утверждается как секунды Unix:

{ "sub": "user_8241", "iat": 1783915890, "exp": 1783919490 }

"Почему этот пользователь выходит из системы?" отвечает конвертированием exp, йо- расшифровать токен в JWT декодер и преобразуйте требование - оба запускают клиентскую сторону, что имеет значение, поскольку вставленный токен является действующим удостоверением (the Руководство по конфиденциальности данных Охватывает почему я отказываюсь ставить токены в серверные инструменты).

логарифмическая корреляция Один инцидент, три службы, три формата: журналы Nginx [13/Jul/2026:09:30:45 +0000], приложение регистрирует ISO 8601, рабочий очереди регистрирует необработанные секунды. Преобразование всего в один формат — это шаг нуля построения временной шкалы.

Интеграция API. Полоса отправляет "created": 1740470400 (секунды). API, созданный JavaScript, отправляет 1740470400000 (мс). API Google отправляют строки RFC 3339. Если вы потребляете все три, преобразование происходит 't время от времени - it's постоянно. Форматируйте полезные нагрузки в Форматтер JSON и конвертировать интересные поля.

Запросы диапазона дат. WHERE created_at >= 1752364800 AND created_at < 1752451200- это правильный день? Перевести обе границы и проверить, в UTC, перед запуском удаления. Связанные: Калькулятор разницы дат «Сколько дней между этими двумя?», конвертер часовых поясов для математических и конференц-семьи, а также синтаксический анализатор для "Когда на самом деле срабатывает этот график?

Часто задаваемые вопросы

Что такое метка времени unix?

Количество секунд, прошедших с 1 января 1970 года, 00:00:00 UTC (эпоха Unix), сохранено как единое целое. It's часовой пояс-независимый по определению - один и тот же момент - одинаковый номер везде на Земле - вот почему it's стандартный формат обмена в операционных системах, языках и базах данных.

Почему у некоторых меток времени 10 цифр, а у других 13?

10 цифр - это секунды (стандартное соглашение UNIX, PHP, большинство API); 13 цифр - миллисекунды (JavaScript's Date.now(), Ява). Разделите на 1000, чтобы перейти от MS к секундам. Смешение двух смен датируется ~ 55 000 лет назад или в январе 1970 года.

Могут ли метки времени UNIX представлять даты до 1970 года?

Да - отрицательные значения отсчитываются назад от эпохи. -86400 31 декабря 1969 г. 32-битная метка времени доходит до 13 декабря 1901 года. Однако некоторые системы и API отвергают отрицательные временные метки, поэтому тестируйте, прежде чем полагаться на них.

В чем проблема Y2038?

переполнение 32-битных подписанных временных меток на уровне 2 147 483 647 - 19 января 2038 г., 03:14:07 UTC - перенос на декабрь 1901 г. Современные 64-битные системы не затронуты, но 32-битные встроенные устройства, устаревший код C и MySQL TIMESTAMP Колонки выставлены. Системные вычисления даты будущего (ипотечные, сертификаты) поражают ошибку за годы до наступления 2038 года.

Почему мое свидание показывается в январе 1970 года?

Нулевая или почти нулевая временная метка достигала вашего кода форматирования - обычно неинициализированное значение, неудачный разбор, возвращающий 0, или секунды, прошедшие там, где ожидались миллисекунды. Дата 1970 года на экране почти никогда не является точкой данных; it's ноль в костюме.

Должен ли я хранить временные метки или строки DateTime в моей базе данных?

Храните UTC в любом случае - тип имеет меньшее значение, чем дисциплина часового пояса. целые числа Unix компактны, сортируются тривиально и полностью уклоняются от синтаксического анализа; timestamptz/DATETIME столбцы удобочитаемы в результатах запросов и поддерживают арифметику дат в SQL. Чего не следует делать, так это хранить локальное время без смещений - потери данных 's вы обнаружите только при следующем переходе DST.

Влияет ли эпоха високосные секунды?

Практически нет. Время Unix делает вид, что високосные секунды don't существуют - каждый день составляет ровно 86 400 секунд, и системы обычно размазывают или переходят на часы, когда наступает високосная секунда. Для кода приложения это не проблема; это имеет значение только в контексте научных временных интервалов, где вместо этого используется время TAI или GPS.

Безопасно ли вставлять временные метки журнала производства в онлайн-конвертер?

Одна только необработанная временная метка мало что показывает, но временные метки обычно перемещаются с контекстом - идентификаторами пользователей, утверждениями о токенах, строками журнала. The Конвертер времени отметки времени На Toolz.dev полностью конвертируется в вашем браузере без передачи данных, поэтому вставка значений прямо из производственных журналов или JWTS ничего не выдает.

Как преобразовать метку времени unix в читаемую дату?

Вставьте число в конвертер и прочитайте UTC и локальные результаты или сделайте это в коде: new Date(ts * 1000).toISOString() В JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) В питоне, date -u -d @ts в Linux. Единственное, что нужно сделать правильно первым, это то, будет ли ваше значение в секундах или миллисекундах - все остальное следует из этого.

Как получить текущую временную метку Unix?

date +%s В раковине, Math.floor(Date.now() / 1000) В JavaScript, int(time.time()) В питоне, SELECT EXTRACT(EPOCH FROM NOW()) в PostgreSQL. Обратите внимание, что JavaScript нечетный: Date.now() Возвращает миллисекунды, поэтому разделение не является необязательным.