Изпълнихте тази заявка за диагностика на времето на вашия MySQL сървър.
select @@time_zone, now(), utc_timestamp()
От вашето местно и универсално време е ясно, че настройката на системната часова зона на вашата сървърна машина е „Канада/Планина“, а сървърният софтуер MySQL няма собствена настройка на часовата зона.
Ако вземете таблиците си и ги преместите непроменени на сървър в някоя близка часова зона, винаги можете да актуализирате софтуера си, за да издадете командата
set time_zone = 'Canada/Mountain';
веднага след като се свържете от вашия софтуер. Това ще накара новата ви MySQL връзка да се държи така, както текущата ви по време на часова зона. Ако притежавате MySQL сървъра, можете да зададете неговата часова зона по подразбиране според указанията на тази страница. http://dev.mysql.com/doc /refman/5.5/en/time-zone-support.html
Сега, ето историята за типовете данни за времето. DATE , TIME и DATETIME всички не знаят часова зона . След като съхраните стойност за дата/час, ще й върнете същата стойност, дори ако промените настройките на часовата си зона.
TIMESTAMP типът данни е чувствителен към часовата зона . Тези елементи от данни винаги се съхраняват в UTC, известен също като Z, време
, по-рано известен като Средно време по Гринуич. Те винаги се преобразуват в UTC при съхраняване и винаги се преобразуват обратно при извличане.
вградените функции
за получаване на текуща дата и час (NOW() и приятели) са чувствителни към часовата зона . Те ще дадат стойности в местно време. Изключение правят трите функции, започващи с UTC_ които дават стойности в UTC време.
Много MySQL приложения за няколко часови зони използват следната оперативна дисциплина:
- Попитайте всеки потребител за предпочитана от него часова зона или я разберете от друга част от лични данни за потребителя. (Тази информация се предоставя на телефоните от мрежата.) Съхранявайте я като удобен за информация за зоната дескриптор на часовата зона („Америка/Ню_Йорк“, „Канада/Планина“, „Европа/Виена“ и т.н.) от името на потребителя.
- При установяване на сесия на MySQL от името на потребителя, задайте часовата зона на потребителя с
set time_zoneзаявка като показаната по-горе. Трябва да направите това веднага след вашетоconnectоперация. - Съхранявайте датите и часовете за потребителите в
TIMESTAMPтипове данни. Те ще бъдат преобразувани в UTC, докато се съхраняват. - Извлечете ги, ако е необходимо. Те ще бъдат преобразувани обратно към местно време.
Идеята е часовата зона на вашия потребител да е част от нейния контекст. Това работи добре, защото ако потребител А е във Ванкувър, а потребител Б в Халифакс и по някаква причина потребител Б преглежда данните за времето на потребител А, те ще бъдат показани на Б в атлантическо време повече или по-малко автоматично.
Също така е добре, защото се справя прозрачно с глобалните капризи на смяната на дневната светлина към стандартното време. Отпечатък за време от миналото лято ще се покаже в местното време от миналото лято.
Много мениджъри на сървъри за глобална употреба задават времето на своя системен сървър или часова зона по подразбиране на MySQL на UTC. (Вашият не.)
Друг начин да се справите с всичко това е начина, по който сте започнали. Изберете часова зона и запазете вашите времеви марки по отношение на тази часова зона. Най-добре е да изберете часова зона, която не се редува между дневна светлина и стандартно време в този случай. След това, когато съхранявате времена в базата данни, преобразувайте яснотата. Ще съхранявате времена от потребители в Отава, като направите нещо подобно.
INSERT INTO tbl (appt) VALUES ( 'whatever-time' - INTERVAL 120 MINUTE)
и ще получите стойностите по същия начин. Това е податливо на грешки, но можете да го накарате да работи.
И накрая, можете сами да извършвате своите преобразувания. Ако искате да знаете колко минути отместване има между произволна часова зона и UTC, опитайте тези две заявки.
set time_zone = 'Canada/Atlantic';
select timestampdiff(minute, utc_timestamp(), now());
По това време на годината това връща -240, което е -4:00. Трябва да използвате минути, а не часове, поради изместването на часовата зона за половин час или четвърт час в някои държави.
И накрая, внимавайте. TIMESTAMP Типовете данни не представляват времена преди 1970 г. И в моя екземпляр MariaDB 10.0 изглежда, че отива по дяволите в кофата веднага след 2038-01-19T03:14:07 UTC, когато времето се прехвърля от 32 бита.
