Comments 23
когда можно будет в 2 часа ночи ощутить себя на все 3.
наоборот же? в два часа на час назад — на час ночи. безусловно через час в новые два можно будет ощутить себя на три по старому, но шутка получается черезчур тонкой.
Кстати, чем объясняется такое нежелание софта использовать системную tzdata? Я могу понять это в версиях под винду, где многие пользователи забивают на обновления системы (либо вообще пользователь может использовать WinXP, которая больше не поддерживается), но в Linux система и приложения обновляются одним и тем же методом, поэтому шанс того, что при старой tzdata окажется новым другой софт достаточно мал (только при ручном обновлении из исходников в обход пакетного менеджера, но в таком случае пользователь должен знать, что делает, а значит догадается пересобрать и tzdata, либо он специально хочет использовать старую).
В FAQ к Java-версии ICU
userguide.icu-project.org/icufaq/icu4j-faq#TOC-TimeZone
В C-версии видимо для совместимости с Java
Кроме того, я думаю дело в поддержке множества платформ. Проще поддерживать свою базу чем для каждой платформы изучать реализацию — ведь ICU не только на POSIX системах работает.
userguide.icu-project.org/icufaq/icu4j-faq#TOC-TimeZone
В C-версии видимо для совместимости с Java
Кроме того, я думаю дело в поддержке множества платформ. Проще поддерживать свою базу чем для каждой платформы изучать реализацию — ведь ICU не только на POSIX системах работает.
Уж если упомянули Symfony Forms, то стоит отметить, что в Symfony 2.6 распрощались с ICU компонентом.
не знал, спасибо, интересно тут больше не само удаление, а то что они обещают поставлять базу для всех локалей, но пока компонента Intl все также не дает создать IntlDateFormatter c отличной от «en» локалью.
Из плюсов ситуация как с java здесь получится не должна (хотя кто знает, я уже и не удивлюсь если они скажут что и tzdata будут поставлять с симфони)
Из плюсов ситуация как с java здесь получится не должна (хотя кто знает, я уже и не удивлюсь если они скажут что и tzdata будут поставлять с симфони)
Как я правильно делаю, когда на серверах в любой стране ставлю время в UTC…
Причем тут это?
Ваш дебильный тезис не имеет никакого смысла, если в вашем проекте используется пересчёт времени в локальную таймзону пользователя. Актуальную базу таймзон в таком случае иметь всё равно надо: неважно какая таймзона исходная, если конвертируте в неправильную, например, Europe/Moscow, у которой старый оффсет +4, это всё равно вас не спасёт.
А вот администраторам сайта, которые вводят в админке какой-то контент с датами, дефолтная таймзона в виде UTC прибавит только головной боли: им придётся каждый раз пересчитывать реальное время события в UTC.
tl;dr: если в проекте даты пересчитываются в локальную таймзону пользователя, обновлять все равно придётся и смысла держать всё в UTC нет никакого.
Ваш дебильный тезис не имеет никакого смысла, если в вашем проекте используется пересчёт времени в локальную таймзону пользователя. Актуальную базу таймзон в таком случае иметь всё равно надо: неважно какая таймзона исходная, если конвертируте в неправильную, например, Europe/Moscow, у которой старый оффсет +4, это всё равно вас не спасёт.
А вот администраторам сайта, которые вводят в админке какой-то контент с датами, дефолтная таймзона в виде UTC прибавит только головной боли: им придётся каждый раз пересчитывать реальное время события в UTC.
tl;dr: если в проекте даты пересчитываются в локальную таймзону пользователя, обновлять все равно придётся и смысла держать всё в UTC нет никакого.
Мой дибильный тезис говорит о том, что сервер должен работать в зоне UTC, клиент должен (и делает это) сообщать о своей временной зоне как смещении от UTC, и при этом не имеет никакого значения что там у вас написано в базе таймзон и есть ли она вообще. При таком подходе данные времени нельзя испортить, хоть правительство раз в несколько дней меняет временную зону — как было некоторое время назад на Украине. А вот ваш удивительно толковый проект накроется медным тазом. Если ваш сервер будет стоять в Донецке, какую он поставит временную зону? Установка как в Москве обвинит вас в сепаратизме, как в Киеве — в бандеровщине. UTC удовлетворит всех. Кроме самого умного ультрахардкора.
Администраторам сайтов UTC временная зона не помешает, если они, как клиенты, пересчитывают время в локальное, и сильно поможет, если они собирают временные события в разных зонах. Администраторы, живущие в разных странах, будут считать хозяина сервера дауном, если время будет в чужой зоне.
В общем, сначала разберитесь в вопросе и поработайте с временами в разных зонах.
Администраторам сайтов UTC временная зона не помешает, если они, как клиенты, пересчитывают время в локальное, и сильно поможет, если они собирают временные события в разных зонах. Администраторы, живущие в разных странах, будут считать хозяина сервера дауном, если время будет в чужой зоне.
В общем, сначала разберитесь в вопросе и поработайте с временами в разных зонах.
Смешение от UTC — это не полная информация о таймзоне, её недостаточно, так как вы не сможете пересчитывать даты в будущем: там, возможно, будет перевод часов, о котором из оффсета узнать не получится.
Если администраторы сайта живут в разных часовых поясах и оперируют своими локальными датами, надо это учитывать в коде, если они живут в одной — серверное время не имеет никакого смысла.
Как вы без актуальной базы таймзон можете сказать сколько времени будет у клиента с таймзоной «Europe/Samara» когда на сервере будет 2015-10-26T16:41:19Z?
Если администраторы сайта живут в разных часовых поясах и оперируют своими локальными датами, надо это учитывать в коде, если они живут в одной — серверное время не имеет никакого смысла.
Как вы без актуальной базы таймзон можете сказать сколько времени будет у клиента с таймзоной «Europe/Samara» когда на сервере будет 2015-10-26T16:41:19Z?
Да клиент будет сообщать свою временную зону как смещение, а не как буквы.
Как пересчитывать в будущем — это уже из области фантастики. Клиент должен сообщать свою зону, а не надеяться на эвристику. Пример я привёл — какое время у клиента в Донецке?
Вообще время — это сложная величина, и всякие алгоритмы хитрее самого тупого рано или поздно приводят к ошибкам.
Как пересчитывать в будущем — это уже из области фантастики. Клиент должен сообщать свою зону, а не надеяться на эвристику. Пример я привёл — какое время у клиента в Донецке?
Вообще время — это сложная величина, и всякие алгоритмы хитрее самого тупого рано или поздно приводят к ошибкам.
Что за чушь?
У меня на сайте есть событие, которое произойдет через год. Пользователь, заходя на сайт, хочет точно знать во сколько по его локальному времени будет это событие. Кто должен пересчитывать дату в таком случае?
У меня на сайте есть событие, которое произойдет через год. Пользователь, заходя на сайт, хочет точно знать во сколько по его локальному времени будет это событие. Кто должен пересчитывать дату в таком случае?
Всё верно. На сайте есть событие, которое должно произойти через год. Даже в этом требовании присутствует неопределённость — что значит «через год»? Процесс занимает ровно один год, (понятие 'год' ещё надо определить), процесс, начавшись 2014.10.26 01:01:01, должен закончиться 2015.10.26 01:01:01, какие бы временные изменения за этот год не произошли, или что-то иное?
Решение простое — надо точно определять используемые понятия.
И надо наконец ответить на мой вопрос — что ваш супералгоритм будет делать с клиентами в Донецке.
Решение простое — надо точно определять используемые понятия.
И надо наконец ответить на мой вопрос — что ваш супералгоритм будет делать с клиентами в Донецке.
Да что ж у вас так жопу рвёт из-за Донецка?
Вы можете просто ответить на вопрос: какое время мне надо показать клиенту с Europe/Samara, если в UTC оно равно 2015-10-26T16:41:19Z?
Вы можете просто ответить на вопрос: какое время мне надо показать клиенту с Europe/Samara, если в UTC оно равно 2015-10-26T16:41:19Z?
Да показывайте какое хотите. Какое это отношение имеет к времени на сервере?????
Такое, что только сервер может иметь актуальную базу таймзон, на клиента в этой ситуации полагаться нельзя, вон ниже подтверждение этим словам.
Да поймите, время на сервере не имеет отношения к показу времени на клиентах, какая бы временная зона на сервере ни стояла. И не имеет сервер актуальной базы клиентских таймзон, я же вам привёл пример с Донецком (и с ДНР/ЛНР та же история). У клиента может быть совершенно своё представление о зонах и может вообще не быть представления какая зона будет через год или через месяц.
Проблема с зоной на сервере возникает тогда (например), когда где-то записывается дата. В лог-файлах, например. Если сервер не в UTC, то раз в год (при переводе времени назад) в логах появляются повторяющиеся даты, и понять какая именно дата должна была быть записана без анализа всего лога не удастся (а может быть и вообще не удастся никакими средствами), а даты в логах очень часто пишутся совершенно стандартными программами без указания зоны. Та же проблема проявляется при передаче времени программе, которая не работает с зонами. То есть, ставя на сервер временную зону, вы получаете проблемы в чисто административных задачах.
Возможно, на моё представление о правильности UTC влияет то, что я имею дело с датами со всего земного шара и клиентами, которые работают именно с датами в UTC — морской транспорт. Но пример с логами от этого не зависит.
Проблема с зоной на сервере возникает тогда (например), когда где-то записывается дата. В лог-файлах, например. Если сервер не в UTC, то раз в год (при переводе времени назад) в логах появляются повторяющиеся даты, и понять какая именно дата должна была быть записана без анализа всего лога не удастся (а может быть и вообще не удастся никакими средствами), а даты в логах очень часто пишутся совершенно стандартными программами без указания зоны. Та же проблема проявляется при передаче времени программе, которая не работает с зонами. То есть, ставя на сервер временную зону, вы получаете проблемы в чисто административных задачах.
Возможно, на моё представление о правильности UTC влияет то, что я имею дело с датами со всего земного шара и клиентами, которые работают именно с датами в UTC — морской транспорт. Но пример с логами от этого не зависит.
Для меня привычнее когда время на сервере соответствует времени которое я как его администратор вижу на своем компьютере
При этом в приложении пользователь может сам выбрать тайм зону которая привычна ему.
А по поводу смещение со стороны клиента — это еще хуже (уже не 2 места где надо обновлять tzdata, а столько сколько клиентов)
На примере — на телефоне у меня нет обновления для tzdata и системное время я руками ставлю правильное, я создаю на нем напоминание на 10:00 (-4) потом открываю это же напоминание на компьютере и вижу 9:00 (+3)…
При этом в приложении пользователь может сам выбрать тайм зону которая привычна ему.
А по поводу смещение со стороны клиента — это еще хуже (уже не 2 места где надо обновлять tzdata, а столько сколько клиентов)
На примере — на телефоне у меня нет обновления для tzdata и системное время я руками ставлю правильное, я создаю на нем напоминание на 10:00 (-4) потом открываю это же напоминание на компьютере и вижу 9:00 (+3)…
Шаманство для тех, кто не хочет, или не имеет возможности обновить базу данных часовых поясов:
Или любая другая зона из списка.
Как временное решение, вполне подходит.
date_default_timezone_set('Europe/Minsk');
Или любая другая зона из списка.
Как временное решение, вполне подходит.
Нашлось более простое решение без перекомпиляции libicu: habrahabr.ru/post/254789/
Хотя да, по началу на Europe/Minsk тоже подменял ))
Хотя да, по началу на Europe/Minsk тоже подменял ))
Sign up to leave a comment.
Перевод часов в России 26 октября и icu4c