Инструменты разработчика · Конвертер временных меток Unix
Целые числа эпох и столбцы временных меток: почему единица принадлежит схеме
· Почему это важно
временные метки базы данных форматы данных
Хранить время как целую эпоху просто и портативно, но только если все согласны с единицей измерения и зоной. В этом посте целые числа сравниваются с собственными типами временных меток и утверждается, что какой бы вариант вы ни выбрали, единица измерения должна быть записана.
создано_at: 1700000000 или 1700000000000? — столбец, который два сервиса писали в разных подразделениях в течение полугода
Столбец с именем `created_at`, содержащий как 1,738,578,000, так и 1,738,578,000,000, не может быть интерпретирован последовательно. Численная сортировка разделяет авторов по масштабу, а не по хронологии, а автоматическое обнаружение у каждого читателя скрывает повреждение, а не устраняет его. В схеме не удалось сохранить требуемую единицу.
Перед миграцией профилируйте значения по производителям и сравните репрезентативные строки с независимыми свидетельствами событий. Не делите все длинные значения вслепую; смешанная колонка требует происхождения или тщательно ограниченной классификации. ToolAcre помогает проверять образцы, но не делает вывод, какая служба написала каждую строку.
Смешанные величины могут также искажать индексы и запросы на сохранение до того, как кто-либо откроет строку. Рассматривайте обнаружение как нарушение целостности данных, а не просто дефект форматирования в одном клиенте.
Случай целочисленных эпох — переносимость, сортировка, арифметика и независимость от настроек часового пояса базы данных.
Целочисленная эпоха компактна для обмена и проста для сравнения, когда начало координат, единица измерения и ширина фиксированы. Он позволяет избежать хранения текста в языковом формате и поддерживает арифметику длительности после нормализации. Эти преимущества исходят от контракта вокруг номера, а не от INTEGER отдельно.
Затраты возникают, когда этот контракт отсутствует: люди не могут прочитать значение напрямую, общий клиент может округлять большие целые числа, а тип столбца ничего не говорит о секундах и миллисекундах. Добавьте суффикс модуля или описание схемы и проверьте авторы на границе.
В целочисленном контракте также должно быть указано округление для ввода долей секунды. Уменьшение уровня, усечение или округление могут назначить граничные события разным секундам, даже если в остальном масштаб верен.
Целочисленные эпохи предлагают простой числовой обмен с компромиссами, определяемыми окружающей схемой.
Собственный темпоральный тип базы данных может предоставлять читаемые операции с датами и отклонять некоторые недопустимые входные данные, но диапазон, семантика часового пояса и рендеринг клиента различаются в зависимости от механизма и типа. Репозиторий временных меток не содержит адаптера базы данных, поэтому он не может ранжировать эти продукты или гарантировать «осведомленность» по общему имени типа.
Прочтите текущую документацию выбранного двигателя и протестируйте драйвер. Некоторые клиенты могут возвращать строки, объекты Date или значения, настроенные по зоне. Собственный тип уменьшает некоторые двусмысленности только тогда, когда понятен точный тип и поведение сеанса; это не универсальная замена модели времени приложения.
Поведение собственной временной метки зависит от базы данных и должно быть проверено в этом движке.
Узкое целое число со знаком и широкое целое число имеют разные диапазоны, но ширина по-прежнему не кодирует масштаб. BIGINT может безопасно хранить много миллисекунд, оставаясь при этом семантически безымянным. И наоборот, 32-битное поле секунд приближается к известной границе, хотя его значения сегодня выглядят обычными.
Заявленные комментарии в рабочей книге являются единственной записью, которая является слишком абсолютной. Имена, типы доменов, ограничения, сгенерированные схемы и спецификации API могут содержать единицу. Используйте более одного принудительного уровня. Человеческие комментарии помогают рецензентам, а код и проверка не позволяют писателю незаметно переключать масштаб.
Ширина и единица измерения поля являются независимыми решениями схемы.
Предположим, что строка, созданная во время известного развертывания 2025, содержит `1738578060000`. В миллисекундах это становится `2025-02-03T10:21:00.000Z`; в секундах это выходит за рамки обычных ожиданий и может выйти за пределы диапазона потребителя. Соседняя строка `1738578060` соответствует тому же моменту, что и секунды.
Эта пара предполагает смешанные единицы, но не доказывает, какие авторы несут ответственность. Сгруппируйте по версии службы, пути приема или величине, а затем проверьте несколько известных событий. Сохраняйте резервные копии и журналы миграции. Конвертер — это линза аудита, а не механизм массовой перезаписи.
Проведите аудит нескольких дат за затронутый период. Одно случайное совпадение может ввести в заблуждение, тогда как согласованный шаблон, специфичный для производителя, поддерживает правило контролируемой миграции.
Рабочий пример: определение масштаба подозрительного устаревшего столбца по известным записям.
Предотвратите повторение, назвав необработанные поля `created_at_s` или `created_at_ms`, выполняя синтаксический анализ на одном адаптере и предоставляя один внутренний мгновенный тип. Сохраните UTC мгновений; применять локальное представление только на краях, обращенных к пользователю. Если текстовое значение API предпочтительнее, требуется явное смещение или Z.
Тесты должны отправлять различимые значения через каждую границу сериализации. Ноль — плохой показатель, потому что обе шкалы совпадают. Утвердите фиксированный момент ISO и пропустите его через реальный драйвер. Это улавливает потери единиц до того, как два сервиса будут по-разному заполнять один столбец в течение нескольких месяцев.
Во время миграции отклоняйте новые записи, которые нарушают выбранный контракт, прежде чем восстанавливать старые строки. В противном случае очистка приведет к активному источнику, который продолжит создавать смешанные данные.
Что здесь не распространяется — функции, специфичные для базы данных, такие как FROM_UNIXTIME и to_timestamp, которые различаются в зависимости от ядра.
В этой статье не описываются `FROM_UNIXTIME`, `to_timestamp` или эквивалентные функции. Их входные единицы, диапазоны и взаимодействия зон принадлежат конкретным механизмам и версиям, ни одна из которых не является частью реализации ToolAcre. Копирование имени функции между базами данных может создать рассматриваемую двусмысленность.
Используйте документацию поставщика и одноразовую таблицу для подтверждения преобразований перед миграцией. Не позволяйте преобразованиям приложения и базы данных применять одно и то же смещение или коэффициент. Одно правильное преобразование легче протестировать, чем цепочку неявных приведений.
Запустите функцию базы данных для граничных приборов в тех же настройках сеанса, что и в рабочей среде. Значения по умолчанию для зоны сеанса могут изменить текстовые результаты, даже если арифметика эпохи верна.
Вывод: схема — это то, где находится единица измерения, и как конвертер временных меток Unix помогает проверять существующие данные, указывая единицу измерения, которую она применила.
Схема должна сделать представление метки времени неудивительным для каждого писателя и читателя. Целые числа могут быть уместны; могут подойти собственные временные столбцы. Безымянной шкалы нет. Выберите один контракт, обеспечьте его соблюдение и рассматривайте преобразование как явную пограничную операцию.
Для получения устаревших данных проверьте образцы под обоими устройствами, сопоставьте их с известными событиями и зафиксируйте неопределенность. Выбор видимых единиц ToolAcre поддерживает это расследование, но окончательное решение о миграции должно приниматься на основе происхождения и фактической семантики базы данных.
Проверка схемы является полной только в том случае, если устройства записи, чтения, индексы и задания хранения используют одну и ту же модель. Исправление только комментария к столбцу оставляет нетронутой двусмысленность исполняемого файла.