Файл timestamp что это

Datetime или timestamp

На днях я столкнулся с тем, что многие разработчики не знают в чём отличие типов данных DATETIME и TIMESTAMP в MySQLе, а так же как хранить дату и время, если необходимо учитывать разные часовые пояса для разных пользователей веб-приложения. Поэтому хочу дать ниже разъяснения с пояснениями.

DATETIME
Хранит время в виде целого числа вида YYYYMMDDHHMMSS, используя для этого 8 байтов. Это время не зависит от временной зоны. Оно всегда отображается при выборке точно так же, как было сохранено, независимо от того какой часовой пояс установлен в MySQL. Даю пример:

mysql> create table `dt1` ( col datetime NOT NULL );
mysql> SET @@session.time_zone=’+00:00′;
mysql> select now();
+———————+
| now() |
+———————+
| 2009-06-04 18:13:56 |
+———————+

mysql> insert into dt1 values(now());

mysql> insert into dt1 values(now());

TIMESTAMP
Хранит 4-байтное целое число, равное количеству секунд, прошедших с полуночи 1 января 1970 года по усреднённому времени Гринвича (т.е. нулевой часовой пояс, точка отсчёта часовых поясов). При получении из базы отображается с учётом часового пояса. Часовой пояс может быть задан в операционной системе, глобальных настройках MySQL или в конкретной сессии. Запомните, что сохраняется всегда количество секунд по UTC (универсальное координированное время, солнечное время на меридиане Гринвича), а не по локальному часовому поясу. Пример:

Ещё одно отличие! TIMESTAMP по умолчанию NOT NULL, а его значение по умолчанию равно NOW().

mysql> insert into dt1 values(null);
ERROR 1048 (23000): Column ‘col’ cannot be null
mysql> insert into tm1 values(null);
Query OK, 1 row affected (0.00 sec)
mysql> select * from tm1;
+———————+
| col |
+———————+
| 2009-06-04 18:25:08 |
| 2009-06-04 18:25:26 |
| 2009-06-04 18:32:50 |
+———————+

Дополнение. Для тех, кого смущает использование функции NOW().

Источник

Timestamp

Timestamp может ссылаться на time code или digitally signed timestamp, который предназначен для подтверждения существования определённого документа в определённое время, как часть электронной подписи.

Timestamp очень полезен для журналирования событий.

Многие источники также используют термин timestamp, имея в виду POSIX-время, количество секунд прошедшее с 00:00:00 UTC 1 января, 1970 года.

Содержание

История

Идея использования временно́й печати (перевод автора «timestamping») информации актуальна довольно давно. Например, когда Роберт Гук открыл свой закон в 1660 году, он не хотел его публиковать, но хотел иметь право на авторство. Поэтому он сначала выпустил анаграмму ceiiinosssttuv и позднее опубликовал перевод ut tensio sic vis (лат: упругость, как сила). Похожая ситуация случилась с Галилеем, в его исследованиях фаз Венеры сперва была опубликована анаграмма. Современный пример, современной исследовательской организации может позднее понадобиться доказать, что их идея была разработана до определённой даты. Один из способов решения — перенести всё на компьютер и записать в лабораторную тетрадь зашифрованный ключ целостности данных. В дальнейшем, для проверки, что файл в хранилище не изменялся, вам надо будет пересчитать зашифрованный ключ и сравнить его с ключом в лабораторной тетради.

Доверие электронной отметке времени

Электронная отметка — это способ достоверно следить за временем создания и модификации документа. «Достоверно» здесь значит, что никто, даже владелец этого документа, не в состоянии изменить однажды созданную информацию так, чтоб её целостность не нарушилась. Административная сторона включает прозрачную сборку управления отметками времени, их создание и обновление.

Защищённая отметка времени — это отметка, выданная при свидетелях. Trusted third party (TTP) ведёт себя как timestamping authority (TSA). Это используется для подтверждения существования определённых данных до определённого момента времени (контракты, данные исследования, медицинские записи и т. п.) без возможности дописывания задним числом. Сложные TSA могут использоваться для повышения надёжности и уменьшения уязвимости.

Создание временной метки

Эта техника основана на цифровых подписях и хеш-функциях. Сначала хеш вычисляется из данных. Хеш — своего рода цифровая контрольная сумма файла оригинальных данных: другая строка битов для установленных данных. Если оригинальные данные были изменены, то это будет результат полностью в другом хеше. Этот хеш посылается TSA, TSA генерирует timestamp для хеша и вычисляет хеш этого объединения. Этот хеш, например, может быть подписан в цифровой форме с приватным ключом TSA. Этот подписанный хеш и timestamp возвращаются на подписанную сторону timestamp, который хранит их с оригинальными данными (см. диаграмму).

Впоследствии оригинальные данные не могут быть вычислены из хеша (поскольку хеш-функция является функцией в одну сторону (необратимой)), TSA никогда не видит оригинальные данные, которые допускается использовать в этом методе для конфиденциальных данных.

Проверка временной метки

Все, кто доверяет создателю временной метки (TSA), могут убедиться, что документ уже существовал на момент времени, который был представлен создателем. Также является неопровержимым тот факт, что оригинальные данные принадлежали лицу, запросившему электронную отметку времени, именно в момент создания этой электронной отметки. Для доказательства этого (см. диаграмму) вычисляется хеш оригинальных данных, к нему добавляется timestamp, полученный от TSA, и вычисляется хеш этого объединения, назовём его хешем A.

Затем проверяется цифровая подпись TSA путём дешифрования подписанного хеша, полученного от TSA, с помощью открытого ключа TSA. В результате получается дешифрованный хеш, который назовём хешем B. Если хеш A идентичен хешу B, значит, электронная отметка времени не подвергалась изменениям и была выпущена TSA. Если хеши не совпадают, можно утверждать, что либо электронная отметка времени была изменена, либо она не была выпущена TSA.

Источник

Файл timestamp что это

Таблица 8.9. Типы даты/времени

Примечание

Тип interval дополнительно позволяет ограничить набор сохраняемых полей следующими фразами:

Типы abstime и reltime имеют меньшую точность и предназначены для внутреннего использования. Эти типы не рекомендуется использовать в обычных приложениях; их может не быть в будущих версиях.

8.5.1. Ввод даты/времени

Помните, что любые вводимые значения даты и времени нужно заключать в апострофы, как текстовые строки. За дополнительной информацией обратитесь к Подразделу 4.1.2.7. SQL предусматривает следующий синтаксис:

8.5.1.1. Даты

Таблица 8.10. Вводимые даты

8.5.1.2. Время

Таблица 8.11. Вводимое время

Таблица 8.12. Вводимый часовой пояс

Подробнее узнать о том, как указывается часовой пояс, можно в Подразделе 8.5.3.

8.5.1.3. Даты и время

В константе типа timestamp without time zone Postgres Pro просто игнорирует часовой пояс. То есть результирующее значение вычисляется только из полей даты/времени и не подстраивается под указанный часовой пояс.

8.5.1.4. Специальные значения

Таблица 8.13. Специальные значения даты/времени

Внимание

8.5.2. Вывод даты/времени

Таблица 8.14. Стили вывода даты/время

Примечание

ISO 8601 указывает, что дата должна отделяться от времени буквой T в верхнем регистре. Postgres Pro принимает этот формат при вводе, но при выводе вставляет вместо T пробел, как показано выше. Это сделано для улучшения читаемости и для совместимости с RFC 3339 и другими СУБД.

Таблица 8.15. Соглашения о порядке компонентов даты

Для большей гибкости при форматировании выводимой даты/времени можно использовать функцию to_char (см. Раздел 9.8).

8.5.3. Часовые пояса

Часовые пояса и правила их применения определяются, как вы знаете, не только по географическим, но и по политическим соображениям. Часовые пояса во всём мире были более-менее стандартизированы в начале прошлого века, но они продолжают претерпевать изменения, в частности это касается перехода на летнее время. Для расчёта времени в прошлом Postgres Pro получает исторические сведения о правилах часовых поясов из распространённой базы данных IANA (Olson). Для будущего времени предполагается, что в заданном часовом поясе будут продолжать действовать последние принятые правила.

Поэтому мы советуем использовать часовой пояс с типами, включающими и время, и дату. Мы не рекомендуем использовать тип time with time zone (хотя Postgres Pro поддерживает его для старых приложений и совместимости со стандартом SQL ). Для типов, включающих только дату или только время, в Postgres Pro предполагается местный часовой пояс.

Postgres Pro позволяет задать часовой пояс тремя способами:

Помимо аббревиатур и названий часовых поясов Postgres Pro принимает указания часовых поясов в стиле POSIX, как описано в Разделе B.5. Этот вариант обычно менее предпочтителен, чем использование именованного часового пояса, но он может быть единственным возможным, если для нужного часового пояса нет записи в базе данных IANA.

Вкратце, различие между аббревиатурами и полными названиями заключаются в следующем: аббревиатуры представляют определённый сдвиг от UTC, а полное название подразумевает ещё и местное правило по переходу на летнее время, то есть, возможно, два сдвига от UTC. Например, 2014-06-04 12:00 America/New_York представляет полдень по местному времени в Нью-Йорк, что для данного дня было бы летним восточным временем (EDT или UTC-4). Так что 2014-06-04 12:00 EDT обозначает тот же момент времени. Но 2014-06-04 12:00 EST задаёт стандартное восточное время (UTC-5), не зависящее о того, действовало ли летнее время в этот день.

Независимо от формы, регистр в названиях и аббревиатурах часовых поясов не важен. (В PostgreSQL до версии 8.2 он где-то имел значение, а где-то нет.)

Параметр конфигурации TimeZone можно установить в postgresql.conf или любым другим стандартным способом, описанным в Главе 18. Часовой пояс может быть также определён следующими специальными способами:

8.5.4. Ввод интервалов

Значения типа interval могут быть записаны в следующей расширенной форме:

Таблица 8.16. Коды единиц временных интервалов ISO 8601

В альтернативном формате:

Таблица 8.17. Ввод интервалов

8.5.5. Вывод интервалов

Стиль sql_standard выдаёт результат, соответствующий стандарту SQL, если значение интервала удовлетворяет ограничениям стандарта (и содержит либо только год и месяц, либо только день и время, и при этом все его компоненты одного знака). В противном случае выводится год-месяц, за которым идёт дата-время, а в компоненты для однозначности явно добавляются знаки.

Вывод в стиле iso_8601 соответствует « формату с кодами » описанному в разделе 4.4.3.2 формата ISO 8601.

Таблица 8.18. Примеры стилей вывода интервалов

Источник

Файл timestamp что это

Таблица 8.9. Типы даты/времени

Примечание

Примечание

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

Для типа time p может принимать значения от 0 до 6 при хранении типа в восьмибайтном целом и от 0 до 10 при хранении в числе с плавающей точкой.

Тип interval дополнительно позволяет ограничить набор сохраняемых поле следующими фразами:

Типы abstime и reltime имеют меньшую точность и предназначены для внутреннего использования. Эти типы не рекомендуется использовать в обычных приложениях; их может не быть в будущих версиях.

8.5.1. Ввод даты/времени

Помните, что любые вводимые значения даты и времени нужно заключать в апострофы, как текстовые строки. За дополнительной информацией обратитесь к Подразделу 4.1.2.7. SQL предусматривает следующий синтаксис:

8.5.1.1. Даты

Таблица 8.10. Вводимые даты

8.5.1.2. Время

Таблица 8.11. Вводимое время

Таблица 8.12. Вводимый часовой пояс

Подробнее узнать о том, как указывается часовой пояс, можно в Подразделе 8.5.3.

8.5.1.3. Даты и время

В константе типа timestamp without time zone Postgres Pro просто игнорирует часовой пояс. То есть результирующее значение вычисляется только из полей даты/времени и не подстраивается под указанный часовой пояс.

8.5.1.4. Специальные значения

Таблица 8.13. Специальные значения даты/времени

8.5.2. Вывод даты/времени

Таблица 8.14. Стили вывода даты/время

Примечание

ISO 8601 указывает, что дата должна отделяться от времени буквой T в верхнем регистре. Postgres Pro принимает этот формат при вводе, но при выводе вставляет вместо T пробел, как показано выше. Это сделано для улучшения читаемости и для совместимости с RFC 3339 и другими СУБД.

Таблица 8.15. Соглашения о порядке компонентов даты

Для большей гибкости при форматировании выводимой даты/времени можно использовать функцию to_char (см. Раздел 9.8).

8.5.3. Часовые пояса

Часовые пояса и правила их применения определяются, как вы знаете, не только по географическим, но и по политическим соображениям. Часовые пояса во всём мире были более-менее стандартизированы в начале прошлого века, но они продолжают претерпевать изменения, в частности это касается перехода на летнее время. Для расчёта времени в прошлом Postgres Pro получает исторические сведения о правилах часовых поясов из распространённой базы данных IANA (Olson). Для будущего времени предполагается, что в заданном часовом поясе будут продолжать действовать последние принятые правила.

Поэтому мы советуем использовать часовой пояс с типами, включающими и время, и дату. Мы не рекомендуем использовать тип time with time zone (хотя Postgres Pro поддерживает его для старых приложений и совместимости со стандартом SQL ). Для типов, включающих только дату или только время, в Postgres Pro предполагается местный часовой пояс.

Postgres Pro позволяет задать часовой пояс тремя способами:

Вкратце, различие между аббревиатурами и полными названиями заключаются в следующем: аббревиатуры представляют определённый сдвиг от UTC, а полное название подразумевает ещё и местное правило по переходу на летнее время, то есть, возможно, два сдвига от UTC. Например, 2014-06-04 12:00 America/New_York представляет полдень по местному времени в Нью-Йорк, что для данного дня было бы летним восточным временем (EDT или UTC-4). Так что 2014-06-04 12:00 EDT обозначает тот же момент времени. Но 2014-06-04 12:00 EST задаёт стандартное восточное время (UTC-5), не зависящее о того, действовало ли летнее время в этот день.

При этом следует использовать возможность указания часового пояса в стиле POSIX с осторожностью, так как при этом могут быть приняты заведомо неверные данные, потому что разумность аббревиатуры никак не проверяется. Например, команда SET TIMEZONE TO FOOBAR0 будет работать и система примет эту довольно оригинальную аббревиатуру для UTC. Также следует учитывать, что в названиях часовых поясов POSIX положительные смещения соответствуют сдвигу к западу Гринвича. Во всех остальных формах Postgres Pro следует соглашению ISO-8601, по которому положительным смещениям соответствует сдвиг к востоку от Гринвича.

Независимо от формы, регистр в названиях и аббревиатурах часовых поясов не важен. (В PostgreSQL до версии 8.2 он где-то имел значение, а где-то нет.)

Параметр конфигурации TimeZone можно установить в postgresql.conf или любым другим стандартным способом, описанным в Главе 18. Часовой пояс может быть также определён следующими специальными способами:

8.5.4. Ввод интервалов

Значения типа interval могут быть записаны в следующей расширенной форме:

Таблица 8.16. Коды единиц временных интервалов ISO 8601

В альтернативном формате:

Таблица 8.17. Ввод интервалов

8.5.5. Вывод интервалов

Стиль sql_standard выдаёт результат, соответствующий стандарту SQL, если значение интервала удовлетворяет ограничениям стандарта (и содержит либо только год и месяц, либо только день и время, и при этом все его компоненты одного знака). В противном случае выводится год-месяц, за которым идёт дата-время, а в компоненты для однозначности явно добавляются знаки.

Вывод в стиле iso_8601 соответствует « формату с кодами » описанному в разделе 4.4.3.2 формата ISO 8601.

Таблица 8.18. Примеры стилей вывода интервалов

Источник