Будущее Местное время места с использованием широты и долготы

Question

Я разрабатываю приложение для путешествий.

, для этого мне нужно рассчитать будущую местную дату-время для местоположения, используя Datetime (будущую дату), долготу и широту.(Например: я хочу рассчитать местное время и дату местоположения 10 августа 2010 г., 11.23. Из-за перехода на летнее время смещение даты и времени может измениться, поэтому мне нужно преобразовать август 10.10.2010 в 23.23.время расположения) у меня есть входные данные долготы, широты и даты времени. Я могу рассчитать текущую локальную дату, используя долготу и широту, но не могу точно рассчитать для ** будущей даты из-за выключенного времени перехода на летнее время **.off set может варьироваться в зависимости от будущих дат.

Я использую asp.net и c #.

Может ли кто-нибудь помочь?

Answer 1

Вот статья Microsoft о рекомендациях DateTime в .NET , которая охватывает локализацию с учетом перехода на летнее время.

Короче говоря, убедитесь, что вы используете универсальное время и смещения по Гринвичу.

DateTime.ToUniversalTime()

Метод

преобразует любой существующий объект DateTime в UTC-версию. Помните, что смещения UTC работают на основе долготы - основной меридиан равен нулю долготы, поэтому время смещения по Гринвичу = 0. Для Калифорнии смещение по Гринвичу будет составлять минус 800.

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

http://madskristensen.net/post/Get-language-and-country-from-a-browser-in-ASPNET.aspx

Answer 2

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

• Знание стандартного смещения и смещения DST не помогает, поскольку вы не будете знать, когда они применяются.
• Знание только страны (или даже страны и языка) не поможет, поскольку вы не будете знать регион.
• Даже с точным положением вам понадобится довольно точный сервис, чтобы сопоставить каждую возможную точку на земле с правильным часовым поясом

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

Как только вы получите TimeZoneInfo (или время Ноды ITimeZone), все остальное относительно легко, используя DateTime или DateTimeOffset (или ZonedDateTime в Нода) Начать правильно с часового пояса, что сложно.

РЕДАКТИРОВАТЬ: Я только что нашел этот вопрос , который предполагает, что Geonames может быть вашим другом. Я не удивлюсь, если он предоставит вам имя часового пояса Олсона, поэтому вам придется либо использовать конвертер для определения идентификатора часового пояса Windows, либо что-то подобное. (Дайте мне знать, если вы заинтересованы в использовании предварительной версии Noda; эта часть довольно стабильна AFAIK.)

Обратите внимание, что на ваш вопрос нельзя ответить однозначно из-за политических изменений. Иногда правительства вносят изменения в часовые пояса с очень небольшим предупреждением. Пару лет назад Аргентина за 11 дней уведомила , что, например, они не собираются соблюдать ТЛЧ. Кроме того, политические границы могут меняться со временем. По сути, вы должны надеяться, что этого не произойдет.

Answer 3

Я предполагаю, что вы используете долготу для вычисления смещения по Гринвичу, но похоже, что вам нужно сделать что-то вроде этого.

1. Используйте Lat, Long, чтобы определить, в какой стране (Локаль) пункт назначения
2. Получите будущую дату, используя эту локаль, и посмотрите на ее смещение по Гринвичу, включая любое смещение DST (это было давно, так как я смотрел на это на C #, но я уверен, что это довольно очевидно).
3. Как только вы узнаете смещение по Гринвичу и летнему времени для локали, вам будет достаточно просто выполнить все, что вам нужно.

Помните, что летнее время контролируется страной, часто по законодательству и может быть изменено.Большинство библиотек кодов дат стараются поддерживать эту информацию в актуальном состоянии, но она может измениться в краткосрочной перспективе.Например: в 2000 году Новый Южный Уэльс в Австралии изменил свое летнее время, чтобы сделать Олимпийские игры более доступными для американской и европейской аудитории.