Манипуляции со временем (про часовые пояса...)

[untied]

Манипуляции со временем (про часовые пояса...)

Работаю над сайтом компании, занимающейся логистикой.
Заказчик хочет, чтобы на сайте можно было посмотреть день и час прибытия того или иного груза в пункт назначения (или промежуточный пункт). Все бы хорошо, но компания немножко международная, и пользователь может смотреть время прибытия, будучи где-нибудь в Штатах или в Японии. Т.е. время должно быть адекватным для пользователя.

Положим, время веб-сервера можно настроить на UTC. В базе создать объект "часовой пояс" и каждому пользователю назначать тот или иной пояс на выбор.
Допустим, объект "часовой пояс" будет хранить разницу в часах и минутах в сравнении с UTC.
Все бы хорошо, стандартных часовых поясов всего 24, разница между ними час. Но по жизни, все не так: в России, к примеру, действует "декретное", а не поясное время, в Индии разница с UTC 5 ч. 30 мин. (что на 30 мин. больше поясного) и т.д. Вариаций множество, короче говоря. В принципе, все вариации можно учесть (напр. добавить для Индии свой отдельный часовой пояс), но тут опять засада -- перевод на зимнее/летнее время, который происходит у всех по-разному, причем без привязки к дате, а более абстрактно (напр. "в последнее воскресенье октября"). А UTC, насколько я понимаю, сезонными переходами времени не страдает.

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

 

[iceman]

использовать GMT, как был в GMT +5, так и остаюсь...

 

[Lightning]

Если компания "немножко" международная, то, насколько я понимаю, это значит, что стран пользователей не так много, несколько штук. В базе эти данные не нужны. Создай для каждой страны класс, который будет вычислять время в этой стране.

 

[Xeon303]

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

 

[untied]

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

Ладно, пока на UTC остановлюсь. А там посмотрим. : )

 

[флоппик]

Кхм. Вообще, надо все временные промежутки хранить в UTC. А при показе пользователю выводить с учетом смещения его часового пояса. (А лучше рядом и просто относительно от UTC указывать)

 

[untied]

Автор оригинала: флоппик
Кхм. Вообще, надо все временные промежутки хранить в UTC. А при показе пользователю выводить с учетом смещения его часового пояса. (А лучше рядом и просто относительно от UTC указывать)

Ты не догоняешь. Об том и речь, что вычислить адекватное время для пользователя проблематично. Часовых поясов, как выясняется, не 24, а несколько больше. А с учетом нестандартизированного перехода на летнее/зимнее время задачка вообще немеренно усложняется.
Врубайся. : )

 

[флоппик]

смеялсо в голос. Лучше всего свой часовой пояс знает естественно пользователь. И он его знает, он в нем живет.

 

[untied]

Автор оригинала: флоппик
смеялсо в голос. Лучше всего свой часовой пояс знает естественно пользователь. И он его знает, он в нем живет.

О! Да у тебя есть готовое решение. Супер! Поделись тогда, пожалуйста, советом, как мне разрешить подобную ситуацию:
Грузовик прибывает в Мумбай в 10 часов по UTC. На сайте в базе создается соответствующая запись (разумеется, время сохраняется в UTC). На сайт заходит клиент из Финляндии, и ему нужно показать, во сколько грузовик прибыл по финскому времени и (желательно), который был час в Мумбае.
И все это нужно пересчитывать автоматом, с учетом временных поясов (которые я знаю, как хранить в базе) и с учетом переходов на летнее/зимнее время (которые я не знаю как хранить).
Собственно, вопрос только в том, как можно в базе данных хранить абстракцию "пояс UTC+3, переход с летнего на зимнее время осуществляется в последнее воскресенье октября, переход на летнее время осуществляется в последнее воскресенье марта". Поясов больше 24, но все-таки конечное количество, а вот вариантов переходов зимнее/летнее даже для одного пояса существует множество. Да, и еще кое-где время переводится больше двух раз в год.

 

[флоппик]

Поделись тогда, пожалуйста, советом, как мне разрешить подобную ситуацию:

Не вопрос, делюсь: http://www.php.net/manual/ru/class.datetimezone.php

 

[untied]

А я где-то говорил про PHP ? ; )))
Я про базу говорил. Проект не на PHP.

Но все равно спасибо! Там какая-то база данных по часовым поясам приблочена. Поковыряюсь в ней, может что нарою.

 

[Xeon303]

untied
так реализуй на том языке, на котором пишешь приложение. Какая разница?

Для каждого пользователя хранить часовой пояс, чего тут сложного? Вон, в phpBB то же самое уже сто лет работает, и нормально.

 

[untied]

Автор оригинала: Xeon303
untied
так реализуй на том языке, на котором пишешь приложение. Какая разница?

Да я уже понял, что туплю. Пишу на Java, и там есть готовый класс TimeZone, у которого своя встроенная база по часовым поясам (и которую он откуда-то берет).
Единственное, что не нравится -- в классе TimeZone идентификаторы поясов хранятся в строковом виде (напр. "Asia/Kamchatka"). Т.е. в базе данных для пользователя нужно задавать строковое поле для хранения его пояса, а не числовое. Ну да фиг с ним. Сойдет и так. : )
А... И еще все названия зон выдаются только по-английски, т.е. для русской версии сайта так и будет выдаваться "Asia/Kamchatka" вместо "Азия/Камчатка". Ну это тоже фигня.

Я-то собирался некий универсальный движок по часовым поясам придумать.