Обработка часовых поясов в хранилище?

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

Презентация для пользователей в разных часовых поясах может быть настоящим ублюдком, если вы храните местное время. Это легко настроить на локальный, если ваши необработанные данные находятся в UTC - просто добавьте смещение вашего пользователя, и все готово!

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

Часто в базах данных в прошлом я хранил два-UTC для сортировки, местное время для отображения. Таким образом, ни пользователь, ни компьютер не запутаются.

Теперь, что касается отображения: конечно, вы можете сделать "3 minutes ago" вещь, но только если вы храните UTC - в противном случае, данные, введенные в разных часовых поясах, будут делать такие вещи, как отображение как "-4 часа назад", что будет пугать людей. Если вы собираетесь отображать фактическое время, люди любят иметь его в своем местном времени - и если данные вводятся в нескольких часовых поясах, вы можете сделать это с легкостью, только если вы храните UTC.

Ответ, как всегда, будет "depends".

Это зависит от того, что вы описываете со временем, и как данные были предоставлены вам. Ключ к решению о том, как хранить значения времени, - это решить, теряете ли Вы информацию, отбрасывая timezone, а также не удивлять своих пользователей.

Есть определенные преимущества в хранении данных в UTC time_t - это единый int, позволяющий быстро сортировать и легко хранить.

Я вижу эту проблему как разбитую на конкретные области:

1. исторические данные
2. Будущие, Краткосрочные Данные
3. Будущие, Долгосрочные Данные

Со следующими подклассами на каждом из них:

1. Система Обеспечивает
2. Пользователю Предоставляется

Давайте посмотрим на них по очереди.

Система при условии: я бы рекомендовал запускать системы в UTC, тогда вы избежите проблемы timezone и снова не увидите потери информации (это всегда UTC).

Исторические данные: это такие вещи, как файлы системного журнала, статистика процессов, трассировка, комментарий dates/times, и т. д. Данные не изменятся, и дескриптор timezone не изменится задним числом. Для этого типа данных нет никакой информации, потерянной при хранении информации в UTC, независимо от timezone, в котором она была предоставлена. Итак, отбросьте timezone.

Будущее, долгосрочные данные : это события, которые либо находятся достаточно далеко в будущем, либо будут продолжать происходить. Если они хранятся достаточно долго, дескрипторы timezone гарантированно изменяются. Хорошим примером такого типа данных является "The Weekly Management Meeting". Это данные, которые вводятся один раз, и ожидается, что они будут продолжать работать до бесконечности. Для этих значений важно определить, является ли он системным или пользовательским. Для данных, предоставленных Пользователем, время должно храниться с timezone создателя, все остальное приводит к потере информации. Эта потеря информации становится очевидной, когда определение timezone изменяется и время отображается создателю как имеющее совершенно другое значение!

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

Будущие, краткосрочные данные : это данные, которые быстро становятся историческими или действительны только в течение короткого периода времени. Примерами могут быть интервальные таймеры, рейтинговые переходы и т. д. Для этих данных, поскольку вероятность того, что определение будет изменяться между созданием значения и временем, когда оно станет историческим, невелика, можно было бы избежать отказа от timezone. Однако я обнаружил, что эти значения имеют плохую привычку становиться "Future, Long Term Data".

После того, как вы решили хранить timezone, необходимо позаботиться о том, как он хранится.

• Не храните timezone как смещение или полный дескриптор.

Если вы сохраняете timezone как смещение, что вы делаете, если timezone изменяется? Вы проходите через систему и делаете общее изменение на существующих данных? Если вы это сделаете, то теперь вы сделали неверными любые исторические ценности. Хорошими примерами этой ошибки являются Oracle и iCal. Oracle хранит информацию timezone как смещение от UTC, а iCal включает полный дескриптор для создания timezone.

• Храните его как имя.

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

Если разработчики продолжат хранить все в UTC, независимо от timezone, мы продолжим видеть проблемы, которые мы видели с последней партией изменений timezone.

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

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

Рассмотрим случай повторного назначения. Это происходит в GMT 0000 (для простоты), что составляет 1200 NZST (стандартное время Новой Зеландии) и 1000 AEST в Сиднее, Австралия.

Когда переход на летнее время вступает в силу в одной зоне,что должно произойти с назначением? Стоит ли это делать:

1А. если изменение TZ находится в зоне назначение "owner" (кто забронировал его), то попытайтесь остаться на то же самое время настольных часов (например, 10:00am)?
1Б. Если TZ изменение происходит в одном из других зоны участников собрания тогда нет изменение

Последствия: он движется для все остальные, неожиданно, из-за владельцы TZ меняются, но он остается "the 10am meeting" насколько это возможно владелец обеспокоен.

- 2. Как и выше, но в обратном порядке.

Последствия: он перемещается для владельца собрания (встреча в 10 утра становится встречей в 9 утра, или v/v),, что может быть ожидаемо, но неудобно. Он остается в том же настольном времени для других участников, пока они не пройдут через свой собственный переход TZ.

Ни то, ни другое не идеально. Рассмотрим случай двух встреч, одна из которых была забронирована лицом а в 10 утра по местному времени, а другая была забронирована лицом б с лицом а в качестве посетителя в 9 утра. Если человек а и человек Б находятся в разных TZ-х годах, то изменение DST может легко привести к тому, что они станут дважды забронированными.

Если ваш ум немного искривлен в этот момент, тогда я вполне понимаю.

Суть этого примера заключается в том, что для правильного выполнения любого из этих действий вам нужно знать не только версию UTC местного времени, но и TZ (а не смещение), в котором находился владелец, когда они его заказывали. В противном случае у вас нет другого выбора, кроме как принять вариант 2, молча, даже не сообщая никому, что все изменилось с GMT раз не меняется и только презентация changes...right? (нет, это ловушка, презентация имеет значение, когда ваша встреча в 10 утра движется сама по себе)

Я должен отдать должное моему коллеге и другу Джейсону Поллоку за эту проницательность. Прочтите его мнение здесь, а также последующие обсуждения iCal и VTIMEZONE здесь.