Я борюсь с преобразованием DateTime в UTC, концепцией и всем, что я не правильно понимаю.

Когда я получаю строку даты и времени, скажем «7/10/2013», я просто

  Convert.ToDateTime("7/10/2013").ToUniversalTime();

Это будет записано как "10/10/20134:00:00 утра"в базе данных. Сервер расположен в восточном побережье США (-5). Конечно, в течение июля 2013 года DST все еще наблюдается, поэтому смещение за это время составляет -4, например, дополнительные 4 часа4:00:00 утра"записано как UTC.

Пока я пишу этот пост, сейчас февраль 2014 года, и летнее время не действует, поэтому смещение сейчас равно -5. В моем приложении это смещение, которое я выбираю в своем приложении.

Если я применю смещение -5 к "7 /10/20134:00:00 утра"дата будет" 7 /09/201311:00:00 PM».

Что не так и выходной на один день.

Вопрос 1

Как тогда мне правильно конвертировать время UTC назад? Это означает, что когда пользователь загружает мое приложение прямо сейчас, в феврале 2014 года (со смещением часового пояса -5 в настоящее время), 7 октября 2013 года в 4:00:00 утра должно быть все еще 7 октября 2013 года, а НЕ 7 сентября 2013 года.

Меня смущает то, что .ToUniversalTime () учитывает летнее время сервера, существует ли жесткий набор «универсального времени», на который не влияют местоположения сервера?

Вопрос 2

Что происходит, когда у меня есть серверы как на западном, так и на восточном побережье, для записи в базу данных? Как приложение может определить, основано ли время в формате UTC на восточном или западном побережье?

в основном, как тогда код может сказать, что "7/10/2013 4:00:00 AM" - это время UTC, созданное на восточном побережье (которое указывает на 7 октября 2013 00:00:00 AM для восточного побережья США) и не сервером на западном побережье (что указывает на то, что на 7 сентября 2013 г. 20:00:00 "для западного побережья США)?

Извините, если это звучит глупо. Любой совет приветствуется.

========== Окончательное редактирование, Мое текущее решение ===============

Ответ MiMo имеет смысл. Меня смутили две вещи.

что означает время UTC, хранящееся в базе данных, для сервера?Каково отношение времени сервера к пользователю приложения?

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

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

Моим первоначальным решением было получить смещение часового пояса сервера прямо сейчас и использовать его для добавления / вычитания из UTC, и это тоже неправильно. Как и 10 июля 2013 года, смещение сервера на тот момент было -4. Прямо сейчас, в феврале 2014 года, смещение часового пояса сервера равно -5. Решение этого, конечно, заключается в использовании .ToLocalTime ()

Прежде чем углубиться в предложение Мимо о том, как использовать TimeZone.ToLocalTime (), вот что я сделал, чтобы временно устранить проблему.

Получите дату UTC из базы данных и преобразуйте ее в .ToLocalTime, что показывает сервер. Таким образом, для сервера, 10 июля 2013 года 4:00:00 утра становится 7 октября 2013 года 12:00:00 утра.

Получить смещение часового пояса сервера. Он показывает -5 в настоящее время, так как он находится на восточном побережье США.

Получить смещение часового пояса пользователя. Для западного побережья пользователь выбирает -8 прямо сейчас. Для восточного побережья, пользователь выбирает -5 прямо сейчас.

Получите разницу между часовым поясом пользователя и часовым поясом сервера. Западное побережье -3. Восточное побережье 0.

Вычтите различия из 10.07.2013 в 12:00:00, чтобы у западного побережья была дата исполнения 7/09/2013 21:00:00 PM, а у восточного побережья была дата исполнения 7/10/2013 12:00:00 AM.

Все верно.

Большое спасибо, ребята. Теперь пора копаться в TimeZone.ToLocalTime () и посмотреть, смогу ли я уменьшить шаг 2-5.