Тип данных time sql

Тип данных time sql

MySQL извлекает и выводит величины типа TIME в формате ‘HH:MM:SS’ (или в формате ‘HHH:MM:SS’ для больших значений часов). Величины TIME могут изменяться в пределах от ‘-838:59:59’ до ‘838:59:59’ . Причина того, что «часовая» часть величины может быть настолько большой, заключается в том, что тип TIME может использоваться не только для представления времени дня (которое должно быть меньше 24 часов), но также для представления общего истекшего времени или временного интервала между двумя событиями (который может быть значительно больше 24 часов или даже отрицательным).

Величины TIME могут быть заданы в различных форматах:

    Как строка в формате ‘D HH:MM:SS.дробная часть’ (следует учитывать, что MySQL пока не обеспечивает хранения дробной части величины в столбце рассматриваемого типа). Можно также использовать одно из следующих «облегченных» представлений: HH:MM:SS.дробная часть , HH:MM:SS , HH:MM , D HH:MM:SS , D HH:MM , D HH или SS . Здесь D — это дни из интервала значений 0-33 .

  • Как строка без разделителей в формате ‘HHMMSS’ , при условии, что строка интерпретируется как дата. Например, величина ‘101112’ понимается как ’10:11:12′ , но величина ‘109712’ будет недопустимой (значение раздела минут является абсурдным) и преобразуется в ’00:00:00′ .
  • Как число в формате HHMMSS , при условии, что строка интерпретируется как дата. Например, величина 101112 понимается как ’10:11:12′ . MySQL понимает и следующие альтернативные форматы: SS , MMSS , HHMMSS , HHMMSS.дробная часть . При этом следует учитывать, что хранения дробной части MySQL пока не обеспечивает.
  • Как результат выполнения функции, возвращающей величину, приемлемую в контексте типа данных типа TIME (например, такой функции, как CURRENT_TIME ).

Для величин типа TIME , представленных как строки, содержащие разделительные знаки между частями значения времени, нет необходимости указывать два разряда для значений часов, минут или секунд, меньших 10 . Так, величина ‘8:3:2′ эквивалентна величине ’08:03:02’ .

Будьте внимательны в отношении использования «укороченных» величин TIME в столбце типа TIME . MySQL интерпретирует выражения без разделительных двоеточий исходя из предположения, что крайние справа разряды представляют секунды (MySQL интерпретирует величины TIME как общее истекшее время, а не как время дня). Например, можно подразумевать, что величины ‘1112’ и 1112 обозначают ’11:12:00′ (11 часов и 12 минут дня по показаниям часов), но MySQL понимает их как ’00:11:12′ (11 минут, 12 секунд). Подобно этому, ’12’ и 12 интерпретируются как ’00:00:12′ . Величины TIME с разделительными двоеточиями, наоборот, всегда трактуются как время дня. Т.е. выражение ’11:12′ будет пониматься как ’11:12:00′ , а не ’00:11:12′ .

Величины, лежащие вне разрешенного интервала TIME , но во всем остальном представляющие собой допустимые значения, усекаются до соответствующей граничной точки данного интервала. Например, величины ‘-850:00:00’ и ‘850:00:00’ преобразуются соответственно в ‘-838:59:59’ и ‘838:59:59’ .

Недопустимые значения величин TIME преобразуются в значение ’00:00:00′ . Отметим, что поскольку выражение ’00:00:00′ само по себе представляет разрешенное значение величины TIME , то по хранящейся в таблице величине ’00:00:00′ невозможно определить, была ли эта величина изначально задана как ’00:00:00′ или является преобразованным значением недопустимой величины.

ПРИМЕНЯЕТСЯ К: SQL Server (начиная с 2008) База данных SQL Azure Хранилище данных SQL Azure Parallel Data Warehouse

Определяет время дня. Время без учета часового пояса в 24-часовом формате.

Свойство Значение
Синтаксис время [(точность в долях секунды)]
Использование ОБЪЯВИТЕ @MyTime time(7)

CREATE TABLE Таблица1 (Столбец1 time(7) )

точность в долях секунды Задает число знаков для долей секунды.

Может быть целым числом от 0 до 7. Для Informatica это может быть целое число от 0 до 3.

Точность долей секунды по умолчанию равна 7 (100 нс).

Формат строковых литералов по умолчанию

(используется для клиента нижнего уровня)

чч [.ннннннн] (чч [.nnn] для Informatica)

Дополнительные сведения см. в подразделе «Обратная совместимость для клиентов низкого уровня» следующего раздела.

Диапазон 00:00:00.0000000 через 23:59:59.9999999 (типам через 23:59:59.999 для Informatica) Диапазоны элементов Обозначение чч состоит из двух цифр, представляющих час, и принимает значения от 0 до 23.

Обозначение мм состоит из двух цифр, представляющих минуты, и принимает значения от 0 до 59.

Обозначение сс состоит из двух цифр, представляющих секунды, и принимает значения от 0 до 59.

Обозначение n* может содержать от нуля до семи цифр, представляющих доли секунды, и принимает значения от 0 до 9999999. Для Informatica n* равно нулю до трех цифр, в диапазоне от 0 до 999.

Длина в символах минимально 8 позиций (ЧЧ) до 16 максимально (чч:мм:сс.ннннннн). Для Informatica максимальное — 12 (hh:mm:ss.nnn). Точность, масштаб

(только пользовательский масштаб)

См. в следующей таблице. Объем памяти 5 байт, по умолчанию используется фиксированная точность 100 нс. В Informatica, значение по умолчанию — 4 байта, фиксированный, значение по умолчанию 1 мс доли второй точности. Точность 100 наносекунд (1 миллисекунде в Informatica) Значение по умолчанию 00:00:00

Это значение используется для добавления компонента времени при неявном преобразовании даты для datetime2 или datetimeoffset.

Определяемая пользователем точность в долях секунды Да Учет и сохранение смещения часового пояса Нет Учет перехода на летнее время Нет
Указанный масштаб Результат (точность, масштаб) Длина столбца (в байтах) Дробная часть

precision

время (16,7) [(12,3) в Informatica] 5 (4 Informatica) 7 (3 в Informatica) Time(0) (8,0) 3 0-2 Time(1) (10,1) 3 0-2 Time(2) (11,2) 3 0-2 Time(3) (12,3) 4 3-4 Time(4)

Не поддерживается в Informatica.

(13,4) 4 3-4 Time(5)

Не поддерживается в Informatica.

(14,5) 5 5-7 Time(6)

Не поддерживается в Informatica.

(15,6) 5 5-7 Time(7)

Не поддерживается в Informatica.

(16,7) 5 5-7

В следующей таблице приведены допустимые строки литералов форматы для время тип данных.

SQL Server Description
чч:мм[сс][:доли секунд][AM][PM]

чч AM[PM]

Значение часа 0 означает час после полуночи (AM), независимо от указания литерала «AM». Если час равен 0, «PM» указывать нельзя.

Значения часа от 01 до 11 представляют часы до полудня, если указан AM» или «PM. Если задан параметр «AM», то эти значения так же представляют часы до полудня. Если указано «PM», то эти значения указывают на часы после полудня.

Читайте также:  Iconbit movie one прошивка

Значение 12 представляет час, начавшийся в полдень, если не указано «PM» или «AM». Если указано «AM», это значение представляет час, начавшийся в полночь. Если указано «PM», то это значение представляет час, начавшийся в полдень. Например, 12:01 — это 1 минута после полудня, так же как и 12:01 PM, тогда как 12:01 AM — это 1 минута после полуночи. 12:01 АМ аналогично указанию 00:01 или 00:01 AM.

Значения часов от 13 до 23 представляют часы после полудня, если не указано «AM» или «PM». Если задан параметр «PM», то эти значения также представляют часы после полудня. Если час принимает значение от 13 до 23, то указывать «AM» нельзя.

Значение часа, равное 24, недопустимо. Для представления полночи используется 12:00 AM или 00:00.

Миллисекундам может предшествовать либо двоеточие (:), либо точка (.). Число после двоеточия обозначает тысячные доли секунды. При использовании точки однозначное число обозначает десятые доли секунды, двузначное число — сотые, а трехзначное — тысячные доли секунды. Например: 12:30:20:1 означает 20 секунд и одну тысячную долю секунды после 12:30, 12:30:20.1 означает 20 секунд и одну десятую секунды после 12:30.

ISO 8601 Примечания
чч:мм:сс

чч:мм[:сс][.доли секунды]

чч — двузначное число от 0 до 14, представляющее количество часов в смещении часового пояса.

обозначение мм состоит из двух цифр, представляющих дополнительное смещение часового пояса в минутах, и принимает значения от 0 до 59;

интерфейс ODBC Примечания
Зависит от API-интерфейса ODBC.

Использование 24-часового формата и секунды координации свыше 59 согласно стандарту ISO 8601 (5.3.2 и 5.3) не поддерживается с целью обратной совместимости и соответствия существующим форматам даты и времени.

Формат строковых литералов по умолчанию (который используется для клиента нижнего уровня) соответствует стандарту языка SQL, определенному в форме чч.мм:сс[.ннннннн]. Такой формат напоминает определение стандарта ISO 8601 для типа TIME, за исключением долей секунд.

Некоторые клиенты нижнего уровня не поддерживают время, даты, datetime2 и datetimeoffset типов данных. В следующей таблице показано сопоставление типов экземпляра более высокого уровня SQL Server и клиентов низкого уровня.

Тип данных SQL Server Формат строкового литерала по умолчанию, передаваемый клиенту низкого уровня ODBC низкого уровня OLEDB низкого уровня JDBC низкого уровня SQLCLIENT низкого уровня
время чч:мм:сс[.ннннннн] SQL_WVARCHAR или SQL_VARCHAR DBTYPE_WSTR или DBTYPE_STR Java.sql.String String или SqString
Дата ГГГГ-ММ-ДД SQL_WVARCHAR или SQL_VARCHAR DBTYPE_WSTR или DBTYPE_STR Java.sql.String String или SqString
datetime2 ГГГГ-ММ-ДД чч:мм:сс[.ннннннн] SQL_WVARCHAR или SQL_VARCHAR DBTYPE_WSTR или DBTYPE_STR Java.sql.String String или SqString
DateTimeOffset ГГГГ-мм-дд чч [.ннннннн] [+ -] чч: мм SQL_WVARCHAR или SQL_VARCHAR DBTYPE_WSTR или DBTYPE_STR Java.sql.String String или SqString

При преобразовании в типы данных даты и времени SQL Server отвергает все значения, которые он не распознает как значения даты или времени. Сведения об использовании функций CAST и CONVERT с данными даты и времени см. в разделе CAST и CONVERT (Transact-SQL)

Преобразование типа данных time(n) в другие типы данных даты и времени

В этом разделе описано, что происходит при время тип данных преобразуется в другие типы данных даты и времени.

Если преобразование выполняется в time(n), час, минуты и секунды копируются. Если целевая точность меньше исходной точности, доли секунд будут округлены в сторону увеличения, чтобы соответствовать целевой точности. Следующий пример показывает результаты преобразования значения time(4) в значение time(3) .

Если преобразование в
Дата, преобразование завершается неудачей, и возникает сообщение об ошибке 206: «конфликт типов операндов: date несовместим с времени».

Если преобразование выполняется в datetime, час, минуту и второго значения копируются; и компонента даты устанавливается значение «1900-01-01 ". Если точность в долях секунды из time(n) значение больше трех цифр, datetime результат усекается. Следующий код демонстрирует результаты преобразования значения time(4) в значение datetime .

Если преобразование выполняется в smalldatetime, даты устанавливается значение «1900-01-01» и значения часов и минут округляются. Секунды и доли секунд устанавливаются в значение 0. Следующий код демонстрирует результаты преобразования значения time(4) в значение smalldatetime .

Если преобразование выполняется в datetimeoffset(n), даты устанавливается значение «1900-01-01», а также время копируется. Для смещения часового пояса устанавливается значение +00:00. Если точность в долях секунды из time(n) значение больше, чем точность datetimeoffset(n) значение, значение округляется в соответствии с. В следующем примере демонстрируются результаты преобразования значения типа time(4) в тип datetimeoffset(3) .

При преобразовании в datetime2(n), даты устанавливается значение «1900-01-01», компонент времени копируется и смещения часового пояса устанавливается значение 00:00. Если точность в долях секунды из datetime2(n) значение больше, чем time(n) значение, значение будет округляться в соответствии с. Следующий пример показывает результаты преобразования значения time(4) в значение datetime2(2) .

Преобразование строковых литералов в тип time(n)

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

Строковый литерал входа Правило преобразования
ODBC DATE Строковые литералы ODBC сопоставляются с datetime тип данных. Любая операция присваивания литералов ODBC DATETIME в времявызывает неявное преобразование между типами datetime и этот тип в соответствии с правилами преобразования.
ODBC TIME См. правило ODBC DATE выше.
ODBC DATETIME См. правило ODBC DATE выше.
только DATE Указаны значения по умолчанию.
только TIME Простейший.
только TIMEZONE Указаны значения по умолчанию.
DATE + TIME Используется компонент TIME входной строки.
DATE + TIMEZONE Не допускается.
TIME + TIMEZONE Используется компонент TIME входной строки.
DATE + TIME + TIMEZONE Используется компонент TIME локального значения DATETIME.
Читайте также:  Javascript вывести массив на экран

A. Сравнение типов данных даты и времени

В следующем примере сравниваются результаты приведения строкового типа к каждому из даты и время тип данных.

Тип данных Вывод
время 12:35:29. 1234567
Дата 2007-05-08
smalldatetime 2007-05-08 12:35:00
даты и времени 2007-05-08 12:35:29.123
datetime2 2007-05-08 12:35:29. 1234567
DateTimeOffset 2007-05-08 12:35:29.1234567 +12:15

Б. Вставка допустимых строковых литералов времени в столбец time(7)

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

Формат строковых литералов Вставляемый строковый литерал Хранящееся значение time(7) Description
SQL Server ’01:01:01:123AM’ 01:01:01.1230000 Если перед долями секунд стоит двоеточие (:), масштаб не может превышать трех позиций, иначе возникает ошибка.
SQL Server ’01:01:01.1234567 AM’ 01:01:01.1234567 Если указан параметр «AM» или «PM», время сохраняется в 24-часовом формате без литерала «AM» или «PM».
SQL Server ’01:01:01.1234567 AM’ 13:01:01.1234567 Если указан параметр «AM» или «PM», время сохраняется в 24-часовом формате без литерала «AM» или «PM».
SQL Server ’01:01:01.1234567PM’ 13:01:01.1234567 Пробел перед литералом «AM» или «PM» является необязательным.
SQL Server ’01AM’ 01:00:00.0000000 Если задан только час, все остальные значения равны 0.
SQL Server ’01 AM’ 01:00:00.0000000 Пробел перед литералом «AM» или «PM» является необязательным.
SQL Server ’01:01:01′ 01:01:01.0000000 Если не заданы доли секунды, каждая позиция, определяемая этим типом данных, равна 0.
ISO 8601 ’01:01:01.1234567′ 01:01:01.1234567 Для соответствия стандарту ISO 8601 используется 24-часовой формат, а не литералы «AM» и «PM».
ISO 8601 ’01:01:01.1234567 +01:01′ 01:01:01.1234567 Необязательная разница во времени (TZD) во входных данных разрешается, но не сохраняется.

В. Вставка строкового литерала времени в столбцы каждого типа данных date и time

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

В MySQL 5 есть несколько типов данных для хранения даты и времени. Это TIMESTAMP, DATE, DATETIME, TIME и YEAR. Все они обладают своими особенностями, и выбор в пользу того или иного календарного типа должен производиться отдельно в каждой конкретной ситуации. Я хотел бы поделиться с вами результатом моего сегодняшнего миниисследования этих типов, в том числе в аспекте работы с временными зонами.

Итак, все календарные типы данных подробно описаны в разделе «10.3. Date and Time Types» руководства по MySQL. А важная информация, касающаяся поддержки СУБД временных зон, расписана в разделе «9.7. MySQL Server Time Zone Support». Все следующее далее базируется на изучении руководства. В то же время, в здесь указаны лишь нюансы выбора в пользу того или иного типа, поэтому этот материал никак не заменяет мануал, но дополняет его.

Вначале краткая характеристика каждого из типов:

  • TIMESTAMP — тип данных для хранения даты и времени. Данные хранятся в виде количества секунд, прошедших с начала «эпохи Юникса». Диапазон значений: 1970-01-01 00:00:00 — 2038-12-31 00:00:00. Занимает 4 байта.
  • YEAR — тип данных для хранения года. Диапазон значений: 1901 — 2155. Занимает 1 байт.
  • DATE — тип данных для хранения даты. Диапазон значений: 1000-01-01 — 9999-12-31. Занимает 3 байта.
  • TIME — тип данных для хранения времени. Диапазон значений: −828:59:59 — 828:59:59. Занимает 3 байта.
  • DATETIME — тип данных для хранения даты и времени. Диапазон значений: 1000-01-01 00:00:00 — 9999-12-31 00:00:00. Занимает 8 байт.

Хозяйке на заметку. Интересно то, что большинство программистов полагают, что понятие «timestamp» — это и есть Unix-время. На самом же деле, timestamp — это метка, которая представляет собой последовательность символов, обозначающих дату и / или время, когда определенное событие произошло. А «время Юникса» (Unix time) или POSIX time — это количество секунд, прошедших с полуночи 1 января 1970 года по UTC. Понятие timestamp шире, чем Unix time.

Проанализировав описание типов, представленное выше, можно сделать практически все выводы о достоинствах и недостатках тех или иных типов. Все довольно просто и очевидно.

Но прежде, чем рассказать об использовании этих типов, хочу заметить, что на практике часто используется другой тип для хранения даты и времени: целочисленное значение (для хранения даты — INT (4 байта), даты и времени — BIGINT (8 байт)). Отличие использования целочисленных типов от DATE и DATETIME лишь в том, что при выводе данные не форматируются, а в вычислениях с датами и временем целые числа требуется преобразовывать в соответствующий календарный тип. Кроме того, не производится проверка на валидность представленного значения перед сохранением. Возможности сортировки сохраняются. Поэтому INT и BIGINT имеет смысл использовать в тех же случаях, как DATE и DATETIME, с целью максимизации переносимости и независимости от СУБД. Других преимуществ я не вижу, если они есть, предлагаю указать в комментах.

Использование календарных типов данный в MySQL

Начнем с самого простого — тип YEAR. Единственное его достоинство — малый размер — всего-то 1 байт. Но из-за этого действует строгое ограничение по диапазону допустимых значений (тип может хранить только 255 разных значений). Мне сложно представить практическую ситуацию, когда может потребоваться хранить года строго в диапазоне от 1901 до 2155. Кроме того, тип SMALLINT (2 байта) дает диапазон, достаточный в большинстве ситуаций для хранения года. А экономить 1 байт на строке в таблице БД в наше время смысла нет.

Читайте также:  Macbook pro retina 13 inch early 2015

Типы DATE и DATETIME можно объединить в одну группу. Они хранят дату или дату и время с довольно широким диапазоном допустимых значений, независимую от установленной на сервере временной зоны. Их использование определенно имеет практический смысл. Но если требуется хранить даты исторических событий, уходящие в прошлое за Нашу эру, придется выбрать другие типы данных. Для хранения дат неких событий, потенциально выходящих за рамки диапазона типа TIMESTAMP (дни рождений, даты выпуска продуктов, избрания президентов, запуски космических ракет и т.д.), отлично подойдут эти типы. При использовании этих типов нужно учитывать один важный нюанс, но об этом ниже.

Тип TIME можно использовать для хранения промежутка времени, когда не нужна точность меньше 1 секунды, и промежутки времени меньше 829 часов. Добавить тут больше нечего.

Остался самый интересный тип — TIMESTAMP. Рассматривать его надо в сравнении с DATE и DATETIME: TIMESTAMP тоже предназначен для хранения даты и/или времени происхождения неких событий. Важное отличие между ними в диапазонах значений: очевидно, что TIMESTAMP не годится для хранения исторических событий (даже таких, как дни рождений), но отлично подходит для хранения текущих (логирование, даты размещения статей, добавления товаров, оформления заказов) и предстоящих в обозримом будущем событий (выходы новых версий, календари и планировщики и т.д).

Основное удобство использования типа TIMESTAMP состоит в том, что для столбцов этого типа в таблицах можно задавать значение по умолчанию в виде подстановки текущего времени, а так же установки текущего времени при обновлении записи. Если вам требуется эти возможности, то с вероятностью 99% TIMESTAMP — именно то, что вам нужно. (Как этоделать, смотрите в мануале.)

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

Итак, тип TIMESTAMP используем для хранения дат и времени свершения событий нашего времени, а DATETIME и DATE — для хранения дат и времени свершения исторических событий, или событий глубокого будущего.

Диапазоны значений — это важное отличие между типами TIMESTAMP, DATETIME и DATE, но не главное. Главное то, что TIMESTAMP хранит значение в UTC. При сохранении значения оно переводится из текущего временной зоны в UTC, а при его чтении — во время текущей временной зоны из UTC. DATETIME и DATE хранят и выводят всегда одно и то же время, независимо от временных зон.

Временные зоны устанавливаются в СУБД MySQL глобально или для текущего подключения.Последнее можно использовать для обеспечения работы разных пользователей в разных временных зонах на уровне СУБД. Все значения времени физически будут храниться в UTC, а приниматься от клиента и отдаваться клинту — в значениях его временной зоны. Но только при использовании типа данных TIMESTAMP. DATE и DATETIME всегда принимают, хранят и отдают одно и то же значение.

Функция NOW() и ее синонимы возвращают значение времени в текущей временной зоне пользователя.

Учитывая все эти обстоятельства, необходимо быть крайне внимательными при изменении временной зоны в пределах подключения к серверу и использовании типов DATE и DATETIME. Если надо хранить дату (например, дату рождения), то никаких проблем не будет. Дата рождения в любой зоне одинаковая. Т.е. если вы родились 1 января в 0:00 UTC/GMT+0, то это не значит, что в Америке будут праздновать ваш день рождения 31 декабря. Но если вы решите хранить время события в столбце DATETIME, то тут уже построить работу с пользовательскими временными зонами на уровне СУБД просто не выйдет. Поясню на примере:

Пользователь X работает в зоне UTC/GMT+2, Y — в зоне UTC/GMT+3. Для соединений пользователей с MySQL установлена соответствующая (у каждого своя) временная зона. Пользователь размещает сообщение на форуме, нас интересует дата написания сообщения.

Вариант 1: DATETIME. Пользователь X пишет сообщение в 14:00 UTC/GMT+2. Значение в поле «дата» сообщения подставляется как результат выполнения функции NOW() — 14:00. Пользователь Y считывает время написания сообщения и видит те же 14:00. Но у него в настройках стоитзона UTC/GMT+3, и он думает, что сообщение было написано не только что, а час назад.

Вариант 2: TIMESTAMP. Пользователь X пишет сообщение в 14:00 UTC/GMT+2. В поле «дата» попадает результат выполнения функции NOW() — в данном случае — 12:00 UTC/GMT+0. ПользовательY считывает время написания сообщения и получает (UTC/GMT+3)(12:00 UTC/GMT+0) = 15:00 UTC/GMT+3. Все получается ровно так, как мы хотим. И главное — пользоваться этим крайне удобно: для поддержки пользовательских временных зон не нужно писать никакой код приведения времени.

Возможности подстановки текущего времени и работы с временными зонами в типе TIMESTAMP настолько весомы, что если вам в неком логе надо хранить дату без времени, все равно стоит использовать TIMESTAMP, вместо DATE, не экономя 1 байт разницы между ними. При этом на «00:00:00» просто не обращать внимания.

Если же вы не можете использовать TIMESTAMP из-за относительно малого диапазона его значений (а обычно это 1—2 случая против 10—15 в базе сайта), придется использовать DATETIME и аккуратно его корректировать значения в нужных местах (т.е. при записи в это поле переводить дату в UTC, а при чтении — во время в зоне считывающего пользователя). Если вы храните только дату, то скорее всего не важно, какая у вас временная зона: новый год все празднуют 1 января по локальному времени, ничего переводить тут не понадобится.

Ссылка на основную публикацию
Adblock detector