Правильная реализация учёта летнего времени

[@ndrey]

Автор оригинала: zerkms
какой ужас. у меня даты уже в UTC в mysql и всю рутину за меня делает mysql.

На самом деле никакого ужаса нет. Хранить дату в TIMESTAMP и перекладывать рутину на мускул может и лучше, но не всегда подходит.

 

[Fortop]

правда с обходом дурацкого массива

Версию сменить и будет_массив более удобный

 

[zerkms]

Fortop
непонятно, почему было не ввести параметры и в параллельную 5.2, которая как бы ещё поддерживаемая. неужели тоже какие-то internal issues не позволяют? %)

 

[Fortop]

zerkms
А можно это спросить у разработчиков?

Ее могли перевести именно в разряд "поддерживаемых" т.е. когда фиксятся баги, но новый функционал не добавляется.

Напиши им в трекер

 

[mz]

эм, не понял зачем массивы, date("I") и date("I", дата_из_базы) ? Что я и предлагал делать.

 

[zerkms]

mz
мде, чота я втупил ага

 

[pilot911]

господа, а как правильно сохранить время в базу?

 

[zerkms]

pilot911
я сохраняю в mysql timestamp.
выше пролистай, я в первом посте описал всё ведь - этот вариант лишён всех недостатков, разве что DST дурацкий %)

 

[pilot911]

Автор оригинала: zerkms
pilot911
я сохраняю в mysql timestamp.
выше пролистай, я в первом посте описал всё ведь - этот вариант лишён всех недостатков, разве что DST дурацкий %)

не понимаю для случая, когда может быть несколько клиентов с разными поясами

допустим, для каждого устанавливаем свой пояс, но кто-то впоследствии пояс будет менять - соответственно, для этого клиента данные из базы будут отличными от того, что он захочет увидеть, верно?

не правильнее ли хранить в базе все данные в UTC-0 ?

 

[zerkms]

pilot911
в базе все данные хранятся в UTC
http://dev.mysql.com/doc/refman/5.1/en/timestamp.html

TIMESTAMP values are converted from the current time zone to UTC for storage, and converted back from UTC to the current time zone for retrieval.

 

[pilot911]

спасибо, с TIMESTAMP разобрался

а как ты решаешь вопрос хранения даты до 1970 года ?

я сейчас использую отрицательные целые от mktime()

 

[zerkms]

никак не решаю не столкнулся ибо.

ps: а нужно ли для дат до 1970 время? если нет - то вполне можно обойтись тем же mysql date

 

[pilot911]

ясненько, спасибо )

-~{}~ 29.03.10 05:09:

прочитал в одном месте - может проблема с выдачей времени с учетом перехода на летнее возникает по причине того, что в мускуле устанавливаешь time_zone как "+04:00", а надо бы - "Asia/Vladivostok" - отсюда мускуль не может определиться с правильностью перехода лето/зима ?

 

[zerkms]

pilot911
вполне вероятно, вот только проблема в том, что по дефолту mysql.time_zone не заполнена нигде...

mysql> select count(*) from mysql.time_zone;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.01 sec)

и решение получается очень настройкозависимое, хотя и сильно более красивое.

 

[pilot911]

Автор оригинала: zerkms
pilot911
вполне вероятно, вот только проблема в том, что по дефолту mysql.time_zone не заполнена нигде...

mysql> select count(*) from mysql.time_zone;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.01 sec)

и решение получается очень настройкозависимое, хотя и сильно более красивое.

да.. есть такое

если не затруднит, чтобы уже закрыть вопрос - потестируй, пож-та, с заполненной таблицей

дамп лежит здесь http://downloads.mysql.com/general/timezone-2009g.zip

 

[zerkms]

mysql> set time_zone = 'Asia/Vladivostok';
Query OK, 0 rows affected (0.01 sec)

mysql> select unix_timestamp('2010-03-28 01:00:00');
+---------------------------------------+
| unix_timestamp('2010-03-28 01:00:00') |
+---------------------------------------+
|                            1269702024 |
+---------------------------------------+
1 row in set (0.00 sec)

mysql> select unix_timestamp('2010-03-28 02:00:00');
+---------------------------------------+
| unix_timestamp('2010-03-28 02:00:00') |
+---------------------------------------+
|                            1269705624 |
+---------------------------------------+
1 row in set (0.00 sec)

mysql> select unix_timestamp('2010-03-28 03:00:00');
+---------------------------------------+
| unix_timestamp('2010-03-28 03:00:00') |
+---------------------------------------+
|                            1269705624 |
+---------------------------------------+
1 row in set (0.00 sec)

угу, с текстовым представлением зоны сразу всё окей.

 

[pilot911]

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

 

[zerkms]

pilot911
прям сейчас у меня функция вывода даты одна. но вообще да, лучше забыть об этой проблеме вообще

 

[pilot911]

верно