Являются ли метки времени Unix лучшим способом хранения меток времени?

Question

Я всегда использую метки времени Unix для всего, но мне интересно, есть ли лучший способ.

Что вы используете для хранения меток времени и почему?

Answer 1

Как бы вы ни хранили метку времени, важно избегать региональных проблем интерпретации и проблем смещения времени. Временная метка Unix интерпретируется одинаково независимо от региона и вычисляется с одного и того же момента времени независимо от часового пояса - это хорошо.

Остерегайтесь хранения меток времени в виде неоднозначных строк, таких как 01/02/2008, поскольку их можно интерпретировать как 02 января 2008 г. или 01 февраля 2008 г., в зависимости от локали.

При хранении часов / минут / секунд важно знать, «какой» час / минута / секунда указывается. Вы можете сделать это, включив информацию о часовом поясе (не требуется для метки времени Unix, поскольку предполагается, что это UTC).

Однако обратите внимание, что временные метки Unix не могут однозначно представлять некоторые моменты времени: когда в UTC есть високосная секунда, временная метка Unix не изменяется, поэтому и 23:59:60 UTC, и 00:00:00 следующего дня имеют одинаковое представление Unix. Так что если вам действительно нужно разрешение в одну секунду или лучше, рассмотрите другой формат.

Если вы предпочитаете для хранения более читабельный формат, чем отметка времени Unix, рассмотрите ISO 8601 .

Одним из методов, который помогает сохранять простоту, является сохранение дат в формате UTC и применение только смещения часового пояса или перехода на летнее время при отображении даты для пользователя.

Answer 2

Если вы храните файл журнала, пожалуйста, ради любви к Питу, сделайте его читабельным и лексически сортируемым.

2008-10-07 09:47:02 например.

Answer 3

32-битные метки времени Unix будут переполнены через несколько лет (январь 2038 г.) , так что это может быть вопросом. Я обычно использую формат DATETIME в SQL, который представляет собой ГГГГ-ММ-ДД ЧЧ: ММ: СС со временем в виде 24-часовых часов. Я пытаюсь вывести файлы в том же формате, чтобы облегчить мне жизнь.

Answer 4

Какую эпоху нужно хранить и в каком разрешении? Если вам нужны микросекунды или даты в каменном веке, time_t может оказаться не лучшим. Для общих бизнес-целей это довольно хорошо (при условии 64-битного)

Answer 5

Метка времени не очень хорошая идея для баз данных, потому что они не учитывают переход на летнее время или текущее местное время. В MySQL лучше хранить его как время, а затем использовать функции даты и времени MySQL для получения нужных частей или сравнения с другими датами.

Answer 6

Зависит от того, для чего вам нужны временные метки.

Метка времени Unix не может представлять время в 1 секунду после 2008-12-31T23: 59: 59Z. Если вы делаете '2009-01-01T09: 00: 00' - '2008-12-31T09: 00: 00' с временными метками Unix, результат НЕ верен: между этими двумя датами будет високосная секунда, и они будут разделены на 86401 секунду (а не на 86400, как отметят временные метки Unix).

Кроме этого и того, что сказали другие респонденты, да - временные метки Unix - это путь:)

Answer 7

timeval-style (time_t + microseconds), если мне нужна точность менее секунды, иначе просто time_t. Вы можете использовать 64-разрядное целочисленное значение для хранения time_t * 1000000 + usec, и вы защищены от переполнения более +/- 292 000 лет.

Answer 8

UNIX Timestamp 32-битная проблема, кажется, довольно раздражает для пользователей, которые вводят будущие даты в 2038 +.

Либо используйте последовательность DATETIME для MySQL, либо сохраните даты в виде BIGINT (8) без знака (макс. 18 квинтиллионов) или FLOAT, чтобы можно было вводить большие числа. Тогда вы не можете использовать, например, функцию PHP date (), потому что она допускает только целые числа в качестве параметра (ограничено 32-битными системами).

Решение, которое я нашел , заключается в использовании PHP 5.2.0 функций. Вот PHP-решение DateTime .

Нет необходимости изменять формат UNIX_TIMESTAMP. Пока у вас есть BIGINT (8) без знака в качестве хранилища MySQL для отметок времени. Вы больше не будете ограничены 32-битными системами.

Answer 9

Отметка времени имеет принципиальное значение:

• отдельный момент времени

И поскольку у момента времени есть бесконечное разрешение, при выборе формата метки времени важно: достаточно ли разрешения?

• Время Unix считается только в секундах.
• Ext 4 имеет наносекунды
• Java имеет наносекунды

Для большинства приложений, которых я имел, достаточно наносекунд. Итак, у Java Timestamp было правильное разрешение для меня.