Time zone map что это

Time zone

Часовые пояса — регионы Земли, в которых принято одинаковое местное время. Иногда в понятие часового пояса включается ещё и совпадение даты — в этом случае пояса UTC+14 будут считаться различными, хотя в них действует одинаковое время суток.

Содержание

Принципы различия

В основу современной системы часовых поясов положено универсальное координированное время (всемирное время), от которого зависит время всех часовых поясов. Для того чтобы не вводить местное время для каждого градуса (или каждой минуты) долготы, поверхность Земли условно поделена на 24 часовых пояса. При переходе из одного часового пояса в другой, значения минут и секунд (времени) сохраняются, изменяется лишь значение часов. Существуют некоторые страны, в которых местное время отличается от всемирного не только на целое количество часов, но ещё дополнительно на 30 или 45 мин. Правда, такие временные зоны не являются стандартными часовыми поясами.

Теоретически 24 часовых пояса земного шара должны ограничиваться меридианами, проходящими на 7°30′ восточнее и западнее среднего меридиана каждого пояса, причем вокруг гринвичского меридиана действует всемирное время. Однако в реальности, для сохранения единого времени, внутри одной и той же административной или природной единицы, границы поясов смещены относительно меридианов; местами некоторые часовые пояса даже «пропадают», теряясь между соседними.

На Северном и Южном полюсах меридианы сходятся в одной точке, и поэтому там понятие часовых поясов, а заодно и местного времени, теряет смысл. Считается, что время на полюсах соответствует всемирному, хотя на станции Амундсен-Скотт (Южный полюс) действует время Новой Зеландии, а вовсе не всемирное.

Летнее время

Дополнительную неоднозначность вносит использование во многих странах «летнего времени». При переходе на летнее время происходит смещение своего времени относительно всемирного. К тому же не везде переход на летнее время и обратно осуществляется одновременно. К примеру, когда в странах Южного полушария лето, в северном полушарии зима, и наоборот.

Декретное время

Следует отметить, что использование в России декретного времени уже учтено при присвоении часового пояса и добавлять лишний час не требуется. На старых картах видно, что, например, Москва отнесена ко 2-му часовому поясу, что с учётом часа из-за декретного времени даёт пояс UTC+3, принятый сегодня.

Список часовых поясов

История часовых поясов

До введения поясного времени в каждом городе использовалось своё местное солнечное время, зависящее от географической долготы. С развитием железных дорог и средств связи возникла необходимость более точной и удобной системы синхронизации. Современная система часовых поясов была внедрена в Северной Америке канадским инженером Сэндфордом Флемингом около 1879 года, а к 1929 получила всемирное распространение. В России системы часовых поясов не существовало вплоть до 1917 года.

См. также

Ссылки

Часовые пояса Google Maps KMZ (файл меток KMZ для Google Earth)

Источник

Geonames, Google Maps, Geocoding, часовые пояса и все, все, все

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

Итак,
Пользователь хочет:

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

Введение

Точку на глобусе можно определить при помощи двух координат — широты и долготы. И это вполне себе известный факт. Но с часовыми поясами возникает загвоздка: в любой точке Земли может быть абсолютно любой часовой пояс. Всё зависит от уровня фантазии управленца на той или иной территории.
Например, для ясности, сейчас на Европейской России истинный полдень, которому положено быть в 12:00, появляется почти на 2 часа позже. В день написания статьи истинный полдень — Солнце в зените в Москве — было в 13:38. На некоторых территориях России получается сдвиг прохождения Солнца по зениту аж на 3 часа.
Вернёмся к цифрам. Мировым правительством сообществом был принят за нулевой меридиан — гринвичский. Часовые пояса вычисляются относительно него и следующим образом. Часовой пояс — это сдвиг локального времени в некоторой точке планеты относительно гринвичского меридиана. Весь глобус делится на 24 частей по меридианам. То есть, берутся базовые меридианы 0°, 15°, 30°, и т.п., и от них отсчитываются часовые пояса ± 7,5°. Таким образом, +00:00 часовой пояс — а обозначается он по-разному: и UTC, и GMT, и GMT+00:00 (разница между UTC и GMT есть, но на практике в большинстве случаев это не применяется) — находится от 7,5° з.д до 7,5° в.д., GMT+01:00 — от 7,5° в.д. до 22,5° в.д. и так далее. Но, помимо этого, есть также границы государств, а также некоторые из государств находятся в так называемой средней полосе, где экономически целесообразно делать сдвиг летом на +01:00(обычно). В южном полушарии летний сдвиг происходит, когда в северном зима. В России также было применено декретное время, из-за которого часы были сдвинуты ещё на час вперёд. На морях и океанах используется часовой пояс, который вычисляется по положению обычным образом. А в Антарктиде, вообще, отдельная история, как это дело считать. Из-за всех этих социально-экономических и политических причин часовых поясов на планете накопилось несколько сотен. А если в программе нужно ещё и время использовать (а часовые пояса меняются и во времени), то со всеми этими сдвигами можно запутаться.

Кстати, бывает, что класс Calendar в Java выдаёт ошибку со сдвигом на час, если инициализировать, например, с текущем временем и часовым поясом, а затем установить время до того, как мы перешли исключительно на летнее время, например, 1988г., то календарь будет выводить часы со сдвигом на 1 час. Лечится это, если постоянно при установке новых миллисекунд заново инициализировать календарь. SimpleDateFormat всегда выдаёт подобную ошибку, потому не советую им пользоваться для старых дат.

Geonames.org — это великолепный ресурс. Там можно как скачать базы данных, так и использовать для этого ресурса родной API. В данной статье я буду использовать как раз API.

Для работы с Geonames нужно регистрировать пользователя, при помощи которого будет доступ к API. А также не забыть его активировать. Для этого зайдите в аккаунт и нажмите там на ссылку: Click here to enable.
Тут документация
Есть даже библиотека для доступа, но библиотеку лично я не использую, потому что иногда возникают ошибки. Напрямую с API через http-запрос работать понятнее.
Лицензия. Можно бесплатно пользоваться этим продуктом.

О Google Maps все знают.
Можно общую справку по использованию Google Maps можно посмотреть тут.

Источник

Общие сведения о часовых поясах

TimeZoneInfoКласс упрощает создание приложений, поддерживающих Часовые пояса. TimeZoneКласс поддерживает работу с местным часовым поясом и временем в формате UTC. TimeZoneInfoКласс поддерживает обе эти зоны, а также любой часовой пояс, сведения о котором предопределены в реестре. Также можно использовать TimeZoneInfo для определения пользовательских часовых поясов, о которых в системе нет сведений.

Основные сведения о часовых поясах

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

Во многих мировых часовых поясах поддерживается переход на летнее время. Переход на летнее время позволяет увеличить количество светлого времени суток за счет перевода времени на один час вперед весной или ранним летом и возврата к обычному (или стандартному) времени поздним летом или осенью. Такие переходы к стандартному времени и с него называются правилами коррекции.

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

Для часовых поясов, поддерживающих правила коррекции, переход на летнее время и с него создает два вида аномальных времен: недопустимые времена и неоднозначные времена. Недопустимое время — это несуществующее значение времени, созданное в результате перехода со стандартного времени на летнее время. Например, если такой переход происходит в указанный день в 2:00 утра и вызывает время изменения до 3:00 утра, то каждый раз интервал между 2:00 утра и 2:59:99 утра является недопустимым. Неоднозначное время — это время, которому могут соответствовать два различных времени в одном часовом поясе. Оно создается при переходе с летнего времени на зимнее время. Например, если такой переход происходит в указанный день в 2:00 утра и вызывает время изменения до 1:00 утра, то каждый раз интервал между 1:00 утра и 1:59:99 утра может быть интерпретирован как стандартное или как летнее время.

Терминология часовых поясов

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

Часовые пояса и класс TimeZoneInfo

.net использует сведения о часовом поясе, предоставляемые операционной системой Windows и хранимые в реестре. Из-за количества часовых поясов Земли не все существующие Часовые пояса представлены в реестре. Кроме того, поскольку реестр является динамической структурой, стандартные часовые пояса можно добавлять в него или удалять из него. Наконец, реестр не обязательно должен содержать исторические данные часового пояса. например, в Windows XP реестр содержит данные только об одном наборе корректировок часового пояса. Windows Vista поддерживает динамические данные часового пояса. Это означает, что один часовой пояс может иметь несколько правил коррекции, которые применяются к определенным интервалам в годах. однако большинство часовых поясов, определенных в реестре Windows Vista и поддерживающем переход на летнее время, имеют только одно или два предопределенные правила коррекции.

Зависимость TimeZoneInfo класса от реестра означает, что приложение, поддерживающее Часовые пояса, не может быть уверенным в том, что в реестре определен определенный часовой пояс. В результате при попытке создать экземпляр определенного часового пояса (отличного от местного часового пояса или часового пояса, представляющего UTC) следует использовать обработку исключений. Кроме того, он должен предоставить возможность продолжить работу приложения, если TimeZoneInfo не удается создать экземпляр требуемого объекта из реестра.

Для решения отсутствия необходимого часового пояса TimeZoneInfo класс включает CreateCustomTimeZone метод, который можно использовать для создания пользовательских часовых поясов, не найденных в реестре. Дополнительные сведения о создании настраиваемого часового пояса см. в разделе как создать часовой пояс без правил коррекции и как создать Часовые пояса с правилами коррекции. Кроме того, можно использовать ToSerializedString метод для преобразования только что созданного часового пояса в строку и его сохранения в хранилище данных (например, в базе данных, текстовом файле, реестре или ресурсе приложения). Затем можно использовать FromSerializedString метод для преобразования этой строки обратно в TimeZoneInfo объект. Дополнительные сведения см. в разделе как сохранить Часовые пояса во внедренном ресурсе и как восстановить Часовые пояса из внедренного ресурса.

Поскольку каждый часовой пояс характеризуется базовым смещением относительно UTC, а также смещением относительно времени UTC, которое отражает любые существующие правила коррекции, время в одном часовом поясе может быть легко преобразовано во время в другом часовом поясе. Для этой цели TimeZoneInfo объект включает несколько методов преобразования, в том числе:

ConvertTimeFromUtc, который преобразует время в формате UTC в заданный часовой пояс.

ConvertTimeToUtc, который преобразует время в заданном часовом поясе в формате UTC.

ConvertTime, который преобразует время в одном указанном часовом поясе во время в другом заданном часовом поясе.

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

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

Источник

Разбираемся в часовыми поясами. Инструкция по безопасной работе со временем

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

Зоны и их преобразования – достаточно тяжелая для изучения тема. Это не проходят в институтах, об этом мало статей на популярных ресурсах. Разработчики учатся работать со временем методом проб и ошибок.

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

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

Не устану повторять случай с коллегой, который работал в лондонском стартапе. Лондон это такой город, от которого отсчитываются часовые пояса, потому что через него проходит нулевой меридиан. Иначе говоря, локальное и общемировое времена в Лондоне одинаковы (не считая обозначения зоны, конечно).

Пока разработка шла в Лондоне, никто и не думал ни про какие зоны, и код писали без их учета. Разработчик с зоной +3 столкнулся с тем, что не проходит ни один тест, потому что время прибито гвоздями без учета пояса. В итоге коллега проработал у них год сидя с переведенными часами. Было проще поменять зону локально, чем исправить код.

Забавно, что бизнес той фирмы был связан с расписанием общественного транспорта, где время имеет решающую роль. Это снова поднимает вопросы о том, кто и как пишет повседневное ПО.

В нашем проекте фронтендер решил, что он умнее системы и что нужно помочь клиенту перевести локальное время в UTC. И тем самым заложил в систему трудноуловимый баг. При отправке объекта Date через Ajax первый автоматически приводится к общемировому времени. Затем срабатывал обработчик коллеги, который тоже корректировал пояс. Получается, что мы дважды вычитали локальное время на клиенте и тем самым портили любую дату с сервера.

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

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

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

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

Для работы со временем лучше сразу брать хорошую стороннюю библиотеку. Время настолько сложная вещь, что редкий язык может похвастаться качественной коробочной реализацией. В Джаваскрипте объект Date убог. В Джаве класс java.util.Date был объявлен deprecated уже с версии 1.1, то есть почти сразу. Родной datetime в Питоне приемлем только для базовых задач.

Не нужно думать, что “мне только оберточку написать”, зато без зависимостей. Время – важно. Пусть будут зависимости, но меньше багов.

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

(Конечно, часовые пояса идут не идеально ровно как полоски на арбузе. Еще недавно в России меняли временные зоны – объединяли и делили соседние. Так, стараниями Медведева в моей родной Чите зимой в 16 часов было уже темно как ночью. Но для простоты будем считать, что пояса распределены равномерно.)

Поэтому фраза “созвонимся в три часа” в общемировом масштаба не значит ничего. По чьему времени в три часа? По Москве? Нью-Йорку? Очевидно, нужна особая метка чтобы обозначить, откуда это время получено. Тогда путем простых вычислений можно перевести время из одной метки в другую. Эта метка и называется временной зоной.

Обозначение у нее может быть разное, например смещение в часах (+03:00), имя части света и города через косую черту (Europe/Berlin) или одна из аббревиатур (CET, Центральное Европейское время), но это уже тонкости стандартов кадирования. Важно то, что теперь время привязано к конкретной местности и может быть преобразовано в универсальное время UTC.

UTC – универсальное координированное время – это современный стандарт отсчета, пришедший на смену GMT. Не будем сейчас разбирать его особенности, достаточно сказать, что на шкале поясов он играет роль нуля: именно от него отсчитываются отрицательные (западные) и положительные (восточные) зоны.

Например, я живу в Воронеже, мой пояс третий по счету на восток, поэтому я могу написать в резюме “when calling, please consider my +3 UTC timezone” или просто “my TZ is +3”. Тогда заказчик из Лондона, у которого нулевой пояс, добавит к своему времени 3 часа и получит мое локальное время.

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

А в поле ts нужно писать только время по UTC, иначе будет ошибка:

Видим, что во второе поле записалось не то, что нужно: правильное время по UTC должно быть 15 часов, а не 18. Вот как нужно было сделать:

Эта и другие ошибки будут рассмотрены ниже.

В различных библиотеках и ORM при выборке подобных дат они восстанавливаются в объекты языка с заполненной часовой зоной (поля tz, zone, tzinfo и тд).

Вариант дат без зон тоже имеет право на жизнь, и на мой взгляд он проще. В команде вы просто соглашаетесь, что все даты хранятся как локальное время по UTC. Все библиотеки имеют функции и методы для работы с таким временем, например, datetime.utcnow() в Питоне, moment.utc() в JS и тд.

При передаче дат клиенту вы кодируете их в ISO-формат с зоной. Если зона UTC, она обозначается буквой Z. Таким образом, в текстовом представлении время, отправляемое клиенту будет выглядеть так:

Слева направо: год, месяц, день, разделитель, часы, минуты, секунды, микросекунды, индикатор нулевой зоны UTC.

При кодировании даты без зоны некоторые библиотеки могут не добавить Z на конце, что может запутать клиента. Обязательно учтите это: добавьте в модуль функцию, которая будет добавлять Z к результирующей строке и пользуйтесь только этой функцией (см. выше о единой кодовой базе для работы со временем).

На этом этапе нельзя не заметить, насколько убог формат JSON: он не может передавать даты и не расширяется.

В обратную сторону с клиента на сервер даты передаются в таком же формате: ISO-строка в UTC с Z на конце в качестве зоны.

Рассмотрим, что делать клиенту с полученной строкой. Легче всего восстановить ее в объект библиотекой moment.js:

Видим, что все правильно: мой пояс +3, часы были увеличены на эту разницу, на конце индикатор +03:00.

В сторону: сейчас кто-то встанет и начнет заливать, что moment.js уже не популярен, и что горячие парни пишут какую-то новую либу на замену ей. Мой совет – шлите лесом таких советчиков. Нам нужно проверенное решение, а не модная поделка.

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

Стоит запомнить: если показ даты требует от вас каких-то махинаций вроде прибавления или вычитания часов, минут или что-то в этом роде – срочно остановитесь, вы гарантированно что-то делаете неправильно. Или должно быть четкое понимание, почему нельзя сделать по-другому.

Рассмотрим основные ошибки, связанные с обработкой времени и как с ними бороться. Начнем с сервера.

Убедитесь, что для получения текущего времени вы используете функцию с utc в ее имени, например, datetime.utcnow() вместо datetime.now() и аналогично в других языках. В PostgreSQL аналогично: почти для всех вызовов временных функций нужно указывать зону UTC. Сравните:

Перевести зону из одной в другую на уровне БД можно следующим оператором:

Источник

Time zone abbreviations list

Here you can check local time in all world-wide time zones list sorted by alphabet. This list includes minor and unofficial time zones. For your convenience there is the choice between the 12 hour am/pm and 24 hour time formats. Interested in one particular timezone? By clicking on its name you can review the local time, UTC/GMT offset and linked time zones.

Sort by: City Name | Country | Time Zone | Area code

Directory of all time zone abbreviations: check local time in any time zone around the globe. View world time table, find out official local time in any time zone.

Источник