API для получения TimeZone временная зона часовой пояс.


Приложение для часовых поясов через Win API в WinRT

Разработка под Windows 8/10 — Приложение для часовых поясов через Win API

Допустим, вы хотите написать приложение Windows Store, в котором выводятся часы для разных городов мира. Вероятно, версия для Windows 8 будет выглядеть примерно так:

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

Разработчик с радостью обнаруживает класс TimeZoneInfo в пространстве имен System и замечает, что статический метод GetSystemTimeZones возвращает коллекцию объектов TimeZoneInfo для всех часовых поясов в мире. Однако при попытке использовать этот метод выясняется, что он недоступен для приложений Windows 8. В приложениях Windows 8 можно получить либо объект TimeZoneInfo для текущего часового пояса, либо тривиальный объект TimeZoneInfo для времени UTC (Universal Coordinated Time).

Однако приложениям Windows 8 доступны функции Win32, способные предоставить большую часть нужной информации. Функция Win32 EnumDynamicTimeZoneInformation перебирает все часовые пояса в мире в формате структур DYNAMIC_TIME_ZONE_INFORMATION:

Это расширенная версия структуры TIME_ZONE_INFORMATION:

Тип WCHAR представляет 16-разрядный символ Юникода, а массивы таких символов обычно представляют строки, завершаемые нуль-символом. Поле StandardName содержит строку вида «Eastern Standard Time», а поле DaylightName — строку вида «Eastern Daylight Time». Поле TimeZoneKeyName в структуре DYNAMIC_TIME_ZONE_INFORMATION содержит ключ реестра Windows. В Windows 8 эти записи реестра находятся в ветке HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Time Zones, а ключ реестра совпадает с StandardName.

Поле Bias содержит количество минут, вычитаемое из времени UTC для получения местного времени. Для восточного побережья США смещение составляет 300 минут. Поле StandardBias всегда равно нулю, тогда как DaylightBias содержит количество минут, вычитаемое из стандартного времени для перехода к летнему времени (обычно -60).

Поля DaylightDate и StandardDate определяют, когда должен происходить переход на летнее время и обратно; информация хранится в формате SYSTEMTIME:

Структура SYSTEMTIME в основном используется функциями Win32 GetLocalTime и GetSystemTime для получения текущего местного времени и времени UTC соответственно. Значения SYSTEMTIME в структуре TIME_ZONE_INFORMATlON специально закодированы для обозначения даты перехода: поля wHour и wMinute обозначают время перехода, поле wMonth обозначает месяц перехода (например, 3 — март), поле wDayOfWeek обозначает день недели перехода (например, 1 — воскресенье), а поле wDay — конкретное вхождение заданного дня недели в заданном месяце (например, 2 — второе воскресенье месяца, или 5 — последнее воскресенье).

Windows различает , которые переключаются между стандартным и летним временем в дни, обозначенные подобным образом, и теми, которые динамически переключают время каждый год. Говорят, что последние используют «динамическое летнее время», но информация по годам напрямую недоступна. Функция с именем GetTimeZoneInformationForYear получает год и указатель на структуру DYNAMIC_TIME_ZONE_INFORMATION, а возвращает указатель на структуру TIME_ZONE_INFORMATION с информацией для указанного года. Функция SystemTimeToTzSpecificLocalTime получает указатель на структуру TIME_ZONE_INFORMATION и указатель на структуру SYSTEMTIME (вероятно, полученный от функции GetSystemTime) и возвращает структуру SYSTEMTIME для местного времени в этом часовом поясе. Таким образом, программам не приходится самостоятельно выполнять преобразование времени.

Такая программа, как ClockRack, должна поддерживать возможность выбора часового пояса для конкретного локального контекста. В идеале она должна напоминать средства выбора часового пояса в Windows 8. Вызовите чудо-кнопки Windows 8, выберите кнопку «Параметры» и нажмите нижнюю кнопку «Изменение параметров компьютера». Кнопка запускает программу со списком настроек. Выберите категорию Общие; в верхней части приложения располагается поле со списком часовых поясов. Каждый часовой пояс определяется смещением от UTC; иногда приводится название часового пояса и во многих случаях — примеры городов.

Например, для «романского часового пояса» в списке отображается строка:

В разделе реестра Windows, содержащем список часовых поясов, метки хранятся под именем «Display», но эта информация не предоставляется функциями Win32. Ее придется извлекать из реестра, а для приложений Windows 8 недоступны функции Win32 для чтения данных из реестра.

Конечно, ничего не мешает вам написать маленькую программу .NET, которая будет обращаться к классу TimeZoneInfo, форматировать полученные строки и определять объект Dictionary, включаемый в программу Windows 8. Код программы .NET, которую я использовал для построения этого списка, приведен в комментарии над определением Dictionary:

Объект Dictionary является частью класса TimeZoneManager из проекта ClockRack. В этом классе я объединил всю логику P/Invoke. Код за пределами TimeZoneManager не обращается ни к каким функциям или структурам Win32.

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

Свойство Bias используется только для сортировки. Поле TimeZoneKey содержит ту же строку, что и поле TimeZoneKeyName в структуре DYNAMIC_TIME_Z0NE_INFORMATION, а свойство Display берется из словаря displayStrings.

Часть класса TimeZoneManager в основном файле TimeZoneManager.cs начинается с определения структур Win32 и объявления трех функций Win32, необходимых для работы класса:

Вспомните, что некоторые поля структур DYNAMIC_TIME_ZONE_INFORMATION и TIME_ZONE_INFORMATlON определяются как массивы WCHAR. В C# это решение не сработает! потому что массив C# всегда представляет собой указатель на блок памяти, выделенной из кучи. Вместо этого атрибут MarshalAs позволяет указать, что эти поля должны интерпретироваться как строки C# с конкретной максимальной длиной.

Конструктор класса TimeZoneManager многократно вызывает EnumDynamicTimeZoneInformation до тех пор, пока не будет получено ненулевое значение — признак конца списка. Количество значений в списке зависит от версии Windows (101 в моей версии). Каждое значение преобразуется к типу TimeZoneDisplayInfo и добавляется в открытую коллекцию с именем DisplayInformation:

Как вы вскоре увидите, это свойство DisplayInformation используется как источник данных (ItemsSource) для ComboBox.

Последний метод TimeZoneManager преобразует время UTC в местное время по ключу часового пояса. Эта же строка используется в поле TimeZoneKeyName структуры DYNAMIC_TIME_ZONE_INFORMATION и в свойстве TimeZoneKey структуры TimeZoneDisplayInfo:

Метод преобразует объект .NET DateTime в структуру Win32 SYSTEMTIME, получает значение dynamic_time_zone_information из закрытого словаря, после чего вызывает метод GetTimeZoneInformationForYear, который возвращает информацию в виде структуры TIME_ZONE_INFORMATION, передаваемой функции SystemTimeToTzSpecificLocalTime. Полученное значение SYSTEMTIME преобразуется обратно к типу .NET DateTime.

Не могу сказать, что я полностью доволен этим методом. Дело в том, что программа ClockRack отображает несколько часов и использует метод CompositionTarget.Rendering для получения обновленного значения DateTime.UtcNow, которое используется для всех часов. (Я решил, что такое решение будет эффективнее, чем вызывать из GetLocalTime функцию Win32 GetSystemTime с получением значения SYSTEMTIME для времени UTC по каждым часам.) Мне не нравится повторный вызов метода GetTimeZoneInformationForYear. В действительности его достаточно вызвать только один раз для каждого часового пояса, а в дальнейшем повторно использовать TIME_Z0NE_INFORMATION в последующих вызовах. Но если программа работает при переходе с 31 декабря к 1 января, потребуется повторный вызов. Я решил не загромождать класс подобной логикой.

Год, передаваемый GetTimeZoneInformationForYear, должен быть годом местного времени, а не годом UTC; это еще один момент, который обрабатывается не совсем корректно. Эти два года теоретически могут различаться только в 24-часовом периоде, включающем Новый год по UTC, и в такой программе это не должно играть роли, потому что переход между стандартным и летним временем происходит намного позднее.

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

Большая часть кода вывода часов (класс, производный от UserControl, с именем TimeZoneClock) была позаимствована в программе AnalogClock из статьи «Создание стрелочных часов в WinRT», но я переработал его для использования модели представления через привязки данных. Также все координаты и размеры были уменьшены в 10 раз. Из-за того, что в очень малом пространстве (например, в режиме Snap View) может отображаться большое количество часов, программа должна быть способна изменять размеры часов в широком спектре.


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

Каждый из двух элементов TextBlock имеет фиксированную высоту из настроек RowDefinition панели Grid, но каждый из них также находится в элементе Viewbox; слишком длинный текст автоматически сжимается по размерам. Каждые часы находятся в панели Grid из одной ячейки, свойству Background которой задается привязка данных. Панель занимает все доступное для нее место. В панели Grid находится элемент Viewbox, изменяющий размер своего содержимого — еще одной панели Grid с фиксированным размером 30 x 20, фактический размер которой определяется элементом Viewbox в зависимости от доступного места:

Оба элемента TextBlock и все элементы RotateTransform имеют привязки к свойствам модели представления. В начале файла TimeZoneClock.xaml видно, что модель представления также включает свойства типа Color с именами Foreground и Background. Файл фонового кода не содержит ничего, кроме вызова InitializeComponent.

Чтобы программа была относительно простой, я решил ограничить фоновый и основной цвета каждых часов 140 цветами, которым присвоены имена и которые, следовательно, соответствуют членам статического класса Colors. Как и следовало ожидать, модель представления класса TimeZoneClock определяет свойства Foreground и Background типа Color, но также она определяет свойства ForegroundName и BackgroundName; при изменении одного из этих свойство другое также изменяется при помощи логики отражения:

Эта модель представления также включает свойство DateTime, при каждом изменении которого также изменяются свойства HourAngle, MinuteAngle и SecondAngle, управляющие тремя объектами RotateTransform в TimeZoneClock.xaml.

Для вывода нескольких часов мне была нужна панель, которая бы позволяла вывести все часы в границах страницы, но с выделением оптимального места для каждого потомка. Панель UniformGrid, разработанная в статье «Пользовательские панели в WinRT», была достаточно близка к тому, что требовалось, но не совсем. Предположим, выводятся семь циферблатов, и UniformGrid определяет, что они должны выводиться в две строки по пять в каждой. UniformGrid поместит пять циферблатов часов в первую строку и два — во вторую. Приложение будет лучше смотреться, если панель распределит часы между двумя строками более равномерно — четыре в одной и три в другой.

Программа ClockRack содержит ссылку на библиотеку, в которой мы разработали элемент UniformGrid, но определяет производную от UniformGrid панель с именем DistributedUniformGrid. Логика этого нового класса выделяет приблизительно равное количество ячеек во всех строках. В пределах одной строки объекты равномерно распределяются по ширине:

Файл MainPage.xaml не содержит практически ничего, кроме определения DistributedUniformGrid для хранения элементов управления с часами:

Конструктор класса MainPage отвечает за заполнение панели DistributedUniformGr >класс ApplicationData из пространства имен Windows.Storage для хранения четырех текстовых полей для каждых часов: название места (выбирается пользователем), ключ часового пояса, названия основного и фонового цветов. Для первых часов данные сохраняются с ключами «0Location», «0TimeZoneKey», «0Foreground» и «0Background»; у вторых часов ключи начинаются с цифры 1 и т.д. При выборке каждого набора параметров создаются и инициализируются объекты TimeZoneClock и TimeZoneClockViewModel:

Как обычно, настройки сохраняются во время обработки события Suspending. Конструктор завершается запуском события CompositionTarget.Rendering. Оно отвечает за использование экземпляра TimeZoneManager для получения местного времени на основании текущего времени UTC с ключом часового пояса для каждых часов:

Правое касание открывает контекстное меню с тремя командами добавления (Add), изменения (Edit) и удаления (Delete) часов. Команды Edit и Delete относятся к конкретным часам, поэтому переопределение OnRightTapped начинается с определения часов, к которым прикоснулся пользователь. Этот объект передается обработчикам трех команд. Даже для команды Add эта информация необходима, потому что логика программы вставляет новые часы после выбранных:

Команда Delete присутствует в меню только в том случае, если в приложении открыто более одних часов:

Илон Маск рекомендует:  Что такое код asp frontpageweb

Для команды меню Add необходимо создать и вставить в коллекцию новый объект TimeZoneClock (с соответствующим объектом TimeZoneClockViewModel). Новые часы всегда вставляются после часов, к которым прикоснулся пользователь:

Конечно, команда Edit требует более сложной обработки. Скорее всего, вы вызовете ее сразу же после добавления новых часов (если только вас не устраивают часы с синим циферблатом на желтом фоне). Команда Edit создает экземпляр SettingsDialog (вскоре этот класс будет рассмотрен более подробно) как потомка объекта Popup. Так как SettingsDialog необходим доступ к экземпляру TimeZoneManager, объект TimeZoneManager передается в конструкторе SettingsDialog. Основная часть кода отвечает за позиционирование Popup, чтобы окно было визуально связано с выбранными часами и не выходило за край экрана:

На иллюстрации показано, как выглядит окно SettingsDialog. В первом поле EditBox просто вводится текстовое описание; три других поля используют поле со списком ComboBox для отображения текущего выделенного элемента. При получении фокуса ввода поле ComboBox открывает список вариантов:

Свойству DataContext объекта SettingsDialog задается значение свойства DataContext изменяемого объекта TimeZoneClock. Оно представляет собой объект TimeZoneClockViewModel, а в файле XAML содержатся привязки к свойствам Location.TimeZoneKey, ForegroundName и BackgroundName этого класса. Обратите внимание: у поля TextBox, привязанного к свойству Location, назначен обработчик события TextChanged; это позволяет файлу фонового кода «вручную» обновлять свойство Location объекта TimeZoneClockViewModel, что приводит к обновлению содержимого верхней части Popup.

Файл фонового кода (приведенный далее) поставляет коллекции для трех элементов управления ComboBox. Список часовых поясов заполняется из свойства DisplayInformation объекта TimeZoneManager, а соответствующая разметка первого поля ComboBox ссылается на свойства TimeZoneKey и Display.

Ч решил использовать класс NamedColor, который мы создали в статье «Шаблон данных DataTemplate в WinRT» для получения коллекции объектов NamedColor. Как видно из файла XAML, шаблон ItemTemplate, используемый для этих двух элементов управления, ссылается на свойства Color и Name класса NamedColor, а в каждом элементе ComboBox свойству SelectedValuePath присваивается свойство Name.

Получение часового пояса клиента в JavaScript

Как я могу собрать информацию о часовом поясе посетителя? Мне нужен часовой пояс, а также часы смещения GMT.

23 ответов

смещение часового пояса-это разница в минутах, между UTC и местным временем. Обратите внимание, что это означает, что смещение является положительным, если локальный часовой пояс находится за UTC и отрицательным, если он впереди. Например, если ваш часовой пояс UTC+10 (австралийское Восточное стандартное время), -600 будет возвращен. Летнее время не позволяет этому значению быть постоянным даже для данной локали

обратите внимание, что не все часовые пояса смещены на целые часы: например, Ньюфаундленд-UTC минус 3h 30m (оставляя летнее время вне уравнения).

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

чтобы получить правильный часовой пояс в JavaScript, вы должны использовать

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

есма-402/1.0 говорит, что timeZone может быть не определено, если не предоставлено конструктору. Однако future draft (3.0) исправил эту проблему, изменив часовой пояс по умолчанию.

в этой версии API интернационализации ECMAScript timeZone свойство останется неопределенным, если нет timeZone собственность была предоставленный в опции объект, предоставленный в Intl.DateTimeFormat конструктор. Однако заявки не должны полагаться на это, поскольку будущее versions может возвращать строковое значение, идентифицирующее среду хоста вместо этого текущий часовой пояс.


в ecma-402/3.0, который все еще находится в черновике, он изменился на

в этой версии API интернационализации ECMAScript 2015, timeZone свойство будет именем часового пояса по умолчанию, если нет timeZone свойство было предоставлено в объекте options, предоставленном Intl.DateTimeFormat конструктор. Предыдущая версия оставила timeZone свойство undefined в этом случае.

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

если вы хотите, чтобы часовой пояс клиента был хорошо отформатирован, вы можете положиться на дату JavaScript.метод toString и do:

Это даст вам » GMT-0400 (EST)», например, включая минуты часового пояса, когда это применимо.

кроме того, с regex вы можете извлечь любую нужную часть:

API для получения TimeZone / временная зона /часовой пояс.

4292 просмотра

3 ответа

46 Репутация автора

В моем клиентском приложении у меня есть информация о широте и долготе из skyhook API на основе его IP

Теперь, основываясь на информации о широте и долготе, мне нужно узнать информацию о часовом поясе клиента. Но в документации API часового пояса Google https://developers.google.com/maps/documentation/timezone/ я вижу, что отметка времени является обязательным полем. В таком случае, что мне нужно сделать.

Также не могли бы вы помочь мне понять, что соответствует отметке времени? Например: — Если мой сервер приложений находится в США (например, часовой пояс PST), и он выполняет вызов API Google, передавая временную метку сервера.

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

Ответы (3)

3 плюса

148469 Репутация автора

В приведенной вами ссылке на документацию четко указано, что отметка времени должна быть в UTC и что она используется для отображения правильного значения смещения DST. Он также будет контролировать, timeZoneName отображается ли поле со словом «Стандарт» или «Дневной свет» в названии.

Если вы не заботитесь об этом и просто хотите timeZoneId поле, то не имеет значения, какую ценность вы передаете.

7 плюса

1392 Репутация автора

Я несколько минут ломал голову над API часового пояса Google , особенно по параметру timestamp. Может быть, это выложит необходимость:

В Сан-Диего у нас (сейчас, в августе) смещение по Гринвичу -8 из-за перехода на летнее время. Однако в ноябре у нас будет смещение по Гринвичу -7 .

Так какое смещение gmt должно вернуть Google? -7 или -8? Они оба действительны, но это зависит от того, в какой день вы проведете измерение.

Введите аргумент метки времени. Запустив службу сейчас и используя значение метки времени августа 2015 года , я получаю следующий ответ:

Но если я перенесу метку времени на ноябрь 2015 года (когда в Сан-Диего не будет летнего времени, я получу следующее):

В обоих случаях rawOffset одинаков, но DST изменился из-за предоставленной мной метки времени. Если вы просто хотите узнать текущий часовой пояс, временная метка не имеет значения.

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


Другими словами, каково значение того, что Сан-Диего, как правило, смещается на 7 часов по Гринвичу. Если вы работаете с часовыми поясами, вы, вероятно, пытаетесь убедиться, что ваше время UTC соответствует тому, что испытывает реальный человек в этом месте. Таким образом, смещение DST является критическим.

Заметки программиста

Блог, посвященный программированию и сисадминистрированию

понедельник, 7 сентября 2015 г.

Текущее время и часовые пояса (time zones) в базе данных Oracle

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

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

1. Часовой пояс сессии/клиента
Текущее значение часового пояса сессии/клиента содержится в SESSIONTIMEZONE.

Это значение может быть изменено командой ниже.

В качестве SESSIONTIMEZONE может быть установлено одно из следующих значений:
— Значение временной зоны ОС (‘OS_TZ’)
— Значение временной зоны базы данных (‘DB_TZ’)
— Смещение временной зоны от UTC (например, ‘-05:00’)
— Имя временной зоны (например, ‘Europe/Minsk’)

Для получения текущего времени в часовом поясе сессии используются переменные CURRENT_DATE, LOCALTIMESTAMP, CURRENT_TIMESTAMP.

Они отличаются друг от друга возвращаемым типом:
CURRENT_DATE возвращает DATE, LOCALTIMESTAMP — TIMESTAMP и CURRENT_TIMESTAMP — TIMESTAMP WITH TIME ZONE

2. Часовой пояс базы данных
Текущее значение часового пояса базы данных содержится в DBTIMEZONE.

Это значение используется для внутреннего хранения полей типа TIMESTAMP WITH LOCAL TIME ZONE. Такие поля преобразуются в/из часового пояса сессии при select/insert действиях, поэтому на самом деле значение DBTIMEZONE не имеет большой важности.
Это не часовой пояс переменных SYSDATE и SYSTIMESTAMP.

3. Часовой пояс операционной системы базы данных
Можно посмотреть используя переменную TZR.

Для получения текущего времени в этом часовом поясе используются переменные SYSDATE и SYSTIMESTAMP.

4. Часовой пояс UTC
В Oracle существет специальная функция sys_extract_utc для преобразования любого значения таймстампа в часовой пояс UTC. Ниже приведены разные варианты её использования.

Timezone API is an extensive time zone API

Working with, and understanding time zones can be a hair pulling experience.
TimezoneAPI makes it easy for you to request an extensive amount of information
about your users based on IP address lookup, address lookup or time zone lookup.

Example: Get information about a user based on IP address

Returns location , timezone and datetime information.

Use your prefered coding language to make the request

Testing 1, 2, 3.. Sign up when you’re ready!

We’ve made it easy for you to test out our API’s. Simply click the «Token» link on each API page and a temporary token is generated instantly. You can generate up to five test tokens. Each token is valid for 20 requests. When you’re ready to put the code into production then sign up for a plan to get a service token.

Service Token (for testing)

A test token has been generated for you. It’s good for 20 requests. Please notice: When using a test token the request reponse time is reduced drastically.

API для получения TimeZone / временная зона /часовой пояс.

Информация, содержащаяся в этом документе, может относиться к функциям и продуктам предварительной версии и может претерпеть значительные изменения до окончательного коммерческого выпуска. Настоящий документ предоставляется «как есть» и служит только для информационных целей. Корпорация Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, в связи с этим документом

Узнайте, как часовые пояса работают с управляемый API EWS и веб-служб Exchange в Exchange.


Дата последнего изменения: 9 марта 2015 г.

Область применения: EWS Managed API | Exchange Online | Exchange Server 2013 | Office 365

Часовые пояса не то, что большинство пользователей предоставить намного определиться. Тем не менее они важные концепции при указании даты и времени с помощью управляемого интерфейса API веб-служб Exchange или веб-служб Exchange. Неправильным часовые пояса в управляемый API EWS или веб-служб Exchange приложение может привести к непредсказуемым последствиям. Обработка часовых поясах должным образом, можно легко до тех пор, пока вы знаете, как.

Если вы используете управляемый API веб-служб Exchange, часовые пояса в большинстве случаев обрабатываются для вас автоматически. Без каких-либо явных действий со стороны пользователя API использует локальный часовой пояс клиентского компьютера и все необходимые преобразование в фоновом режиме. Это очень полезно при нужную влияние, но у вас есть другие параметры.

Один из вариантов — это задание для свойства ExchangeService.TimeZone . Это свойство определяет часовой пояс для всех запросов, выполняемых с управляемый API веб-служб Exchange. Это свойство доступно только для чтения; Единственный способ его настройка — через конструктор класса. Если вы используете ExchangeService(System.TimeZoneInfo) или конструктор ExchangeService (ExchangeVersion, System.TimeZoneInfo) , можно указать конкретного часового пояса как объект System.TimeZoneInfo . Если вы используете один из других конструкторов, не вступят в качестве параметра объект TimeZoneInfo , класс ExchangeService устанавливает для свойства TimeZone значение текущего часового пояса на клиентском компьютере.

Часовой пояс, представленный свойством TimeZone выражаются ли задание конкретного часового пояса, или оставьте его как часовой пояс клиентского компьютера, все даты и времени. Управляемый API веб-служб Exchange предоставляет все свойства даты и времени как System.DateTime структуры. Поэтому если задать все свойства даты и времени, быть нельзя, что время, когда указан обрабатывается в соответствии с значение свойства DateTime.Kind на объекте DateTime . Если свойство Kind имеет значение Unspecified , значение DateTime интерпретируется как в часовом поясе, указанном свойством TimeZone . Если вы читаете свойства даты и времени, все свойства DateTime выражаются в этот часовой пояс.

Илон Маск рекомендует:  Что такое код pg_last_notice

При создании новой встречи или собрания или обновлении существующей встречи или собрания, у вас есть возможность переопределить часовой пояс, указанного в TimeZone для новой встречи объектов. Тем не менее именно то, что можно переопределить зависит от версии схемы веб-служб Exchange , вы используете. Для всех значения свойства ExchangeService.RequestedServerVersion можно задать Appointment.StartTimeZone для использования конкретного часового пояса для встречи или собрания. Если вы используете значение для свойства ExchangeService.RequestedServerVersion , больше, чем Exchange2007_SP1 , вы может также необходимо задать свойство Appointment.EndTimeZone позволяет указать часовой пояс для свойства Appointment.End . Тем не менее иметь в виду, что эти свойства только влияет на интерпретацию даты и времени для создания запроса. При извлечении встречи, время начала и окончания по-прежнему быть выражены в часовом поясе, указанном свойством TimeZone .

При обновлении существующей встречи или собрания, можно изменить часовой пояс для объекта Appointment путем установки свойства StartTimeZone и/или свойство EndTimeZone . Это приведет к применимых раз перенести соответствующим образом. Если выбрать ExchangeService.RequestedServerVersion для Exchange2007_SP1 не удается задать свойство EndTimeZone ; Вместо него будет использоваться значение свойства StartTimeZone .

Версия минимальные сервера запросов

Если не задан с помощью конструктор класса ExchangeService , это свойство имеет значение часовой пояс клиентского компьютера. Все свойства DateTime при создании элементов и при получении существующих элементов выражаются в данном часовом поясе. Зона может быть переопределен в этот раз создания запросов для встречи и собрания по Appointment.StartTimeZone и/или свойство Appointment.EndTimeZone . Если не переопределено свойство Appointment.StartTimeZone , этот часовой пояс считается создания часовой пояс для собраний и встреч.

Если задать новые объекты Appointment , этот часовой пояс используется для интерпретации свойства Appointment.Start и Appointment.ReminderDueBy . Этот часовой пояс рассматривается создание часовой пояс для объекта Appointment .

При получении существующих элементов, это свойство является информационным только. Значения свойств DateTime на существующую встречу всегда отображаются в часовом поясе, указанном свойством ExchangeService.TimeZone .

Если задать новые объекты Appointment , этот часовой пояс используется для интерпретации свойство Appointment.End .

При получении существующих элементов, это свойство является информационным только. Значения свойств DateTime на существующую встречу всегда отображаются в часовом поясе, указанном свойством ExchangeService.TimeZone .

Если вы используете веб-служб Exchange, часовые пояса не обрабатывается для вас автоматически и обстоятельства немного сложнее. Влияние часовые пояса веб-служб Exchange запросы и ответы зависит от нескольких факторов:

The Exchange version specified in the RequestServerVersion element

The time zone specified in the TimeZoneContext element (if present)

The time zone specified in the MeetingTimeZone , StartTimeZone , or EndTimeZone elements (if present on appointments or meetings)

Часовой пояс, указанного в XML-элементы dateTime (если они имеются)

Часовой пояс, указанное в значении элементов dateTime может иметь три формы. Могут читать все сведения в схеме XML, часть 2: типы данных Second Edition, но Перефразируя:

Скоординированному времени (UTC): Заданный параметром «Z». Например, 2014-06-06T19:00:00.000Z

Конкретного часового пояса: Определяется «+» или «-» следуют часов и минут. Например, 2014-06-06T19:00:00.000-08:00

Без часового пояса: Указанной отсутствия любого часового пояса. Например, 2014-06-06T19:00:00.000

Если часовой пояс присутствует в значение dateTime (UTC или конкретного часового пояса), это значение всегда интерпретируется как этого часового пояса. При наличии без часового пояса Интерпретация значение зависит от конкретный набор другие элементы связанных с ними часового пояса.

Этот параметр указан TimeZoneContext?

MeetingTimeZone, StartTimeZone или EndTimeZone представить (элемента календаря, имеющего и только MeetingRequest)?

даты и времени в формате UTC

даты и времени в конкретного часового пояса


даты и времени без часового пояса

Часовой пояс создания встречи и собрания

Да (MeetingTimeZone)

Как часовой пояс, указанные в значение

Elements within the CalendarItem or MeetingRequest element that contains the MeetingTimeZone element are interpreted as the time zone in the MeetingTimeZone element, all others interpreted as UTC

Часовой пояс в элементе MeetingTimeZone

Как часовой пояс, указанные в значение

Да (MeetingTimeZone)

Как часовой пояс, указанные в значение

Elements within the CalendarItem or MeetingRequest element that contains the MeetingTimeZone element are interpreted as the time zone in the MeetingTimeZone element, all others interpreted as UTC

Часовой пояс в элементе MeetingTimeZone

Как часовой пояс, указанные в значение

Exchange2010 и более поздних версий

Да (StartTimeZone и/или EndTimeZone)

Как часовой пояс, указанные в значение

If the StartTimeZone element is present, the value of the Начало and ReminderDueBy elements are interpreted as the time zone in the StartTimeZone element. Otherwise, the value of those elements are interpreted as the time zone in the TimeZoneContext element.

If the EndTimeZone element is present, the value of the Начало element is interpreted as the time zone in the EndTimeZone element. Otherwise, the value of the End element is interpreted as the time zone in the TimeZoneContext element.

Elements outside the CalendarItem or MeetingRequest are interpreted as the time zone in the TimeZoneContext element.

Часовой пояс в элементе StartTimeZone , если этот параметр указан, часовой пояс в элементе TimeZoneContext , если это не так

Exchange2010 и более поздних версий

Как часовой пояс, указанные в значение

Как часовой пояс в элементе TimeZoneContext

Часовой пояс в элементе TimeZoneContext

Exchange2010 и более поздних версий

Да (StartTimeZone и/или EndTimeZone)

Как часовой пояс, указанные в значение

If the StartTimeZone element is present, the value of the Начало and ReminderDueBy elements are interpreted as the time zone in the StartTimeZone element. Otherwise, the value of those elements are interpreted as UTC.

If the EndTimeZone element is present, the value of the Начало element is interpreted as the time zone in the EndTimeZone element. Otherwise, the value of the End element is interpreted as UTC.


Elements outside the CalendarItem or MeetingRequest are interpreted as UTC.

Часовой пояс в элементе StartTimeZone , если этот параметр указан, UTC, если это не так

Exchange2010 и более поздних версий

Как часовой пояс, указанные в значение

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

При создании встречи или собрания, часовой пояс, который применяется к времени начала считается создания часовой пояс для встречи. Помимо Интерпретация date/times при создании встречи или собрания, часовой пояс создания имеет следующие эффекты для элемента:

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

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

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

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

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

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

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

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

Пока разработка шла в Лондоне, никто и не думал ни про какие зоны, и код писали без их учета. Разработчик с зоной +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 часа и получит мое локальное время.

Илон Маск рекомендует:  Как сделать многострочную надпись на tbitbtn


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

Ваш сервер и база данных отвечают за хранение дат. Современные БД (здесь и далее – PostgreSQL) предоставляют два типа полей: это timestamp with time zone и timestamp without time zone , то есть с зоной или без. Если в первое поле записать дату с зоной, то БД сконвертирует ее в UTC, потому что так удобней. А при выводе этой даты в утилитах она будет представлена в локальном времени того пользователя, кто сейчас ее просматривает.

Я создал таблицу с двумя полями: время с зоной и без. Потом записал в поле с временной зоной время с часовым поясом Нью-Йорка. В базе оно будет храниться как 2020-12-13 15:00:00 UTC . Но при выводе я увижу время в консоли в моем локальном времени. Все верно, мой пояс +3, дата была приведена верно.

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

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

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

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

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

Клиент и сервер должны обмениваться друг с другом только датами в UTC. Универсальное время переводится в локальное на стороне клиента исходя из локального смещения относительно нулевого меридиана. Эту величину можно определить методом .getTimezoneOffset() объекта Date на клиенте.

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

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

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

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

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

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

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

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

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

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

При передаче JSON-тела на сервер объект Date не нужно приводить в ISO-строку вручную. Для этого существует метод .toJSON() , который автоматически будет вызван при кодировании внешнего словаря. Например:

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

  • Тип поля указан timestamp with time zone , но вы передаете объект времени без зоны.

В этом случае сервер подставит текущую зону, то есть ту, в которой расположен сервер. Если пользователь расположен далеко, например, на другом континенте, это может вызвать значительные неудобства. Скажем, пользователь из Нью-Йорка (-5 UTC) передал на сервер время «2020-12-12T14:20:00Z» . Сервер расположен в Швейцарии (+1 UTC). По какой-то причине зона была отброшена, и в базу вместо «2020-12-12T23:20:00 UTC» (исходное плюс 5 часов) записалось «2020-12-12T13:20:00 UTC» (исходное минус 1 час). Ошибка в 10 часов! Представьте, что это напоминания о поездке или рассылка смс.

  • Тип поля timestamp without time zone , но в базу пишется локальное время сервера.

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

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


Получить список часовых поясов

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

Добавлено через 4 минуты
Причем надо сформировать не просто название часового пояса а смещение относительго текущего)

30.04.2013, 16:21

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

Таблицы часовых поясов
Господа, кто может подкинуть актуальные варианты таблиц mysql.time_zone.

Ввыводить на форму 12 часовых поясов
Написать программу которая выводить на форму 12 часовых поясов и дату

Windows 7: Исчезновение часовых поясов
Доброго времени суток. Столкнулся со следующей проблемой: хотел настроить дополнительные часы для.

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

Форум

Справочник

Поиск по форуму
Расширенный поиск
К странице.

Илья Кантор, 11 мар 2009 — 22:11

getTimezoneOffset

Синтаксис

Аргументы

Описание, примеры

Смещение часового пояса равняется разнице между универсальным (UTC) и местным временем в минутах. Заметьте, что смещение будет положительным, если местное время отстаёт от UTC, и отрицательным, если оно опережает UTC. Например, если ваш часовой пояс — UTC+10 (Владивостокское зимнее время), то метод вернёт -600.

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

Плохо, что возвращается разницы с противоположным знаком. Скажем, если GMT +3, то функция getTimezoneOffset() покажет — 180, а не +180. Еще нужно дописывать действия, чтобы вернуть с нужным знаком.

не нужно. С минусом — это и будет разница, если нужен модуль, то Math.abs

Как раз таки НУЖНО! Хоть подумал прежде, чем ответить? Допустим сервер для всех пользователей планеты выводит на страницу время публикации статьи в виде универсального (UTC) времени, скажем 14:00. Нужно с помощью JS переделать его на местное время пользователя. Местное время UTC+3 (Москва) означает, что у пользователя время на 3 часа БОЛЬШЕ, чем всемирное универсальное время. Когда на сервере 14:00, местное — 17:00.

Берем функцию new Date().getTimezoneOffset() / 60. Оно выведет -3, вместо логичного +3. То есть, чтобы из серверного времени получить местное, мы должны взять эту функция с ОБРАТНЫМ знаком.

Так в чем проблема то? На стороне сервера время публикации сохранено в UTC, получаешь разницу клиента и прибавляешь ко времени публикации, если положительная разница то будет +3, если отрицательная то -3 часа получиться и все.

Может ваш код не логичен? В таком варианте все норм:

Получение часового пояса

Это не получение часового пояса, а получение сдвига.
Один часовой пояс может несколько сдвигов содержать летом и зимой.


Получить TimeZone по часовому поясу смещение

Мне нужен один часовой пояс, и у меня есть смещение часового пояса.

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

Мне не нравится этот подход, потому что TimeZone позвонит , ZoneInfoFile getZoneIds(int var1) который находится здесь. Это декомпилирован код.

Вы можете видеть, что он перебирает существующие объекты для создания массива идентификаторов зоны, в то время как я просто нужно!

Мой вопрос, есть более эффективный способ сделать это? Мне просто нужен ЛЮБОЙ часовой пояс идентификатор или одного часовой пояс заданного смещения.

ТЛ; др

Не делать то, что вы пытаетесь.

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

Зона представляет собой историю смещений

Ответа на этот вопрос Ole В.В. правильно. Вот немного больше обсуждения.

Мне нужен один часовой пояс, и у меня есть смещение часового пояса.

Не действительно возможно.

Офсетным из-UTC не более чем на несколько часов, минут и секунд впереди или позади, UTC .

Временная зона гораздо больше. Зона является историей последних изменений в офсете , используемых людьми конкретного региона. Зона также имеет правило для настоящих и будущих изменений в смещении для этого региона. Таким образом, временная зона всегда предпочтительнее, чем простое смещение, но только тогда , когда известно , с уверенностью . В вашем случае, вы не знаете зону, и не должны угадать; просто придерживаться с использованием смещения.

Данность смещение не может привести вас к конкретной временной зоне без двусмысленности и без ошибок.

  • Неоднозначность , потому что многие зоны могут одни и те же смещение по совпадению. Например, Europe/Gibralter & Europe/Oslo & Africa/Lagos все одни и те же сегодня офсет, один час больше , чем UTC. Таким образом , с только офсетным из-Гринвичска +01:00 как бы вы знаете , какой подходит?
  • Ошибка , потому что без даты вы не можете знать , что смещение относится к временной зоне. Так , например, три зоны , перечисленные выше , одни и те же смещение сегодня зимой 2020-2020, но летом Gibralter и Осло наблюдать летнее время (DST) означает , что они смещаться в час будет два часа впереди UTC в то время как Лагос остается одинчас больше, чем UTC. И исторически, смещения могут быть изменены по другим причинам, чем DST, как политика во всем мире имеет любопытную склонность к пересмотру зон. Так, например, в два раза за последние десять лет Венесуэла изменила свое компенсировано полчаса. В качестве другого примера в последние года, Россия и Турция изменяли свое мнение о том, на ДСТ, возвращаясь к прежним статическому смещению или изменений в постоянно находиться впереди своего предыдущих статического смещением.

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

Мне просто нужен ЛЮБОЙ часовой пояс идентификатор или один часовой пояс заданного смещения.

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

java.time

Как объяснено в другом ответе, TimeZone и ZoneInfo классы теперь наследие. Они являются частью проблемных старых классов даты и времени, которые вытеснили java.time классов.

Вместо того, чтобы использовать ZoneOffset (смещение-с-UTC) и ZoneId (часовой пояс).

Укажите правильное время имя зоны в формате continent/region , например America/Montreal , Africa/Casablanca или Pacific/Auckland . Никогда не используйте 3-4 письмо аббревиатуры , такие как EST или , IST как они не настоящие часовые пояса, не стандартизирован, и даже не единственный (!).

О java.time

Java.time каркас встроен в Java 8 и более поздних версий. Эти классы вытеснять неприятные старые устаревшие классы даты и времени , такие как java.util.Date , Calendar , и SimpleDateFormat .

Joda время проект, в настоящее время в режиме технического обслуживания , советует миграции в java.time классы.

Чтобы узнать больше, обратитесь к Oracle Учебник . И поиск переполнения стека для многих примеров и объяснений. Спецификация JSR 310 .

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL