Как мне обрабатывать дату и время в другом часовом поясе?

Question

Я занимаюсь разработкой международного программного обеспечения, которое выступает в качестве простого программного обеспечения для управления проектами, и я столкнулся с проблемой. Эта проблема касается даты / часа и часового пояса.
Когда сообщение отправляется из одного часового пояса в другой, я могу сохранить время UTC (GMT) в моей базе данных, а затем отображать его по-разному в зависимости от часового пояса пользователя. Но это невозможно сделать, когда я работаю только с датой.
Если я скажу, что задание связано с 21 марта. Должен ли я считать, что эта дата может быть 20 или 22 в некоторых других странах? Каковы ваши советы по этой проблеме?

Answer 1

Допустим, пользователь в Нью-Йорке устанавливает срок выполнения проекта как «в любое время в понедельник, 26 января». Это означает «в любое время с 06:00 понедельника 26 января по 06:00 вторника 27 января» в Брюсселе и «в любое время с 2000 воскресенья 25 января по 2000 понедельник 26 января» в Лос-Анджелесе.

Таким образом, выполнение задания в 21:00 в понедельник 26 прекрасно в Брюсселе и Нью-Йорке, но слишком поздно в Лос-Анджелесе.

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

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

Answer 2

Если вы не сохраняете минуты и секунды, вы должны предположить, что вводимая дата является желаемой, а не корректировкой по Гринвичу. Просто поместите его в базу данных как есть. Люди на западном побережье должны будут предположить, что срок должен быть одинаковым, независимо от того, где вы находитесь в мире. Если вы хотите настроить часовой пояс, вам нужно будет собрать больше информации, например, часы, минуты и секунды.

Answer 3

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

Answer 4

Вы не сможете достичь того, что пытаетесь сделать, не сохраняя точное время. Вам просто не хватает информации.

Answer 5

SQL 2008 допускает тип данных Date, который не имеет никакого значения времени, связанного с ним. Это позволяет кому-то сказать, что мне нужно сделать это к этой дате, но мне все равно, если это +/- несколько часов. Если выбранная дата - 01.01.2009, но это происходит 1/2/2009 в 2 часа ночи, им, вероятно, все равно.

Когда пользователю нужно что-то сделать к определенной дате и времени, например, к концу рабочего дня 01.01.2009, вам нужно сохранить его в DateTime как UTC и преобразовать его в местное время на стороне клиента.

Это значительно облегчит указание того, что что-то выполнено, либо будет выполнено около определенного дня, либо к определенному времени.

Answer 6

Самое простое решение - просто показать одинаковую дату для всех. В последнем часовом поясе срок будет фактически полуночным.

В противном случае выберите время по умолчанию для крайнего срока в часовом поясе, в котором была создана задача, например, 21 марта 17:00 EST или 22 марта 00:00 EST и отобразите его в местном часовом поясе. Затем разница часовых поясов подтолкнет зрителя к предыдущему или следующему дню.

Answer 7

Возможно, вы захотите сохранить дату в часовом поясе. Это поможет вам в ваших расчетах. SQL Server 2008, например, поддерживает datetimeoffset, который делает именно это . В качестве альтернативы, если вы используете SQL 2005 с небольшими усилиями, вы можете написать свой собственный тип данных SQL CLR для поддержки этого.

Answer 8

Ваше решение зависит от вашего приложения и требований.

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

Скорее всего, если задание или совещание должно состояться в 12 часов вечера 21 марта в Лондоне, тогда это произойдет в 21:30 21 марта в Аделаиде (+0930), но это требование к применению, а не какой-либо зловещий стандарт, связанный с часовым поясом.

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

Answer 9

Если у вас есть один экземпляр БД, я бы сохранил все даты в метке даты и времени вашего сервера БД. Если вы используете метки времени для строк, рассмотрите функцию GetDate () в T-SQL или значение по умолчанию для столбца даты с меткой времени. Тогда у вас есть единственная точка отсчета на все времена. Рассмотрим там формат UTC.

Затем все клиенты, обращающиеся к дате, самостоятельно конвертируются в «местное время», что можно интерпретировать с помощью таких вещей, как: пользовательские настройки, отметка времени на клиентском компьютере и т. Д.

Не зная больше, трудно сказать, какое именно разрешение.