Каковы «стандартные» сокращения часового пояса?

Каковы «стандартные» сокращения часового пояса?

Для этого нет стандартов. Аббревиатуры часовых поясов официально не координируются кем-либо. Некоторые из них используются в IANA TZDB , но многие из них были выбраны случайным образом. Часто обсуждается, какие аббревиатуры следует использовать. Например, посмотрите, сколько сообщений было об австралийских аббревиатурах в архивах списков за апрель 2013 года .

Другой список сокращений часовых поясов можно найти здесь . Если вы посмотрите внимательно, вы увидите, что многие неоднозначны. Например, CST может быть «Центральное стандартное время» (США), «Китайское стандартное время» или «Стандартное время Кубы». EST может быть «Восточное стандартное время» (США) или «Восточное стандартное время» (Австралия).

Некоторые не-австралийцы могут предпочесть AEST , но кто скажет, что A должен быть для Австралии, а не для Америки?

Другой очень распространенный пример: некоторые люди используют HAST для Гавайев, в то время как другие используют HST потому что они могут меньше заботиться об алеутских островах на Аляске (что и должно представлять A ).

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

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

Пожалуйста , не делай этого. Часовой пояс не является смещением, и их гораздо больше, чем 24. Пожалуйста, прочтите wiki темы часового пояса , особенно раздел «Часовой пояс! = Смещение».

Из ваших комментариев:

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

Затем в вашем приложении будут присутствовать многие ошибки. Вы просто не можете сделать это надежно – даже если ваше приложение просто работает в США. Неважно, на каком языке или платформе вы находитесь, любая реализация, которая делает это, будет иметь много ошибок при конверсии.

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

Когда дело доходит до часовых поясов, вы не должны ничего жестко кодировать. Правила часовых поясов изменяются все время, потому что они контролируются политиками в каждой стране мира. В базу данных часовых поясов IANA выпускаются обновления, выпущенные несколько раз в год. На стороне PHP в документации PHP четко указывается, какая версия в настоящее время доступна, и что обновления обрабатываются через timezonedb PECL – который извлекает данные из IANA.

Что касается «популярности» – это тоже очень субъективно. Зоны в TZDB существуют по той или иной причине. Единственное место, которое я знаю, пытающееся ограничить это, – это ActiveSupport :: TimeZone от Ruby on Rails. Они утверждают, что имеют «значимое подмножество из 146 зон», которое вы можете видеть в константе MAPPING на этой странице. Но они не говорят, по какому процессу они решили, что считается значимым, и есть явные упущения. Если вы не знаете, где будут находиться все ваши пользователи, я бы не стал пытаться решить, какие зоны ограничить.

Если то, что ваше после – это что-то другое, что выпадающий список всех 578 зон в TZDB, вы можете попробовать один из таких подходов:

• Представьте два спуска. Первым выбрать страну. Второй – выбрать зону внутри этой страны. В PHP вы можете видеть, что когда вы вызываете DateTimeZone::listIdentifiers , он принимает необязательный параметр $country для фильтрации списка.

  Хорошим примером этого является настройка для Календаря Google:

  

• Используйте элемент управления на основе карты, чтобы ваш пользователь мог выбрать свой часовой пояс по местоположению. Их много, но мой фаворит – это для JavaScript.

  Например, это может выглядеть так:

  

Обратите внимание, что пока он показывает аббревиатуру TZDB EDT здесь – это просто используется для удобства отображения. Под капотом вы выбираете значение, например America/New_York .

В конечном счете, вам нужно сохранить для каждого пользователя свой ключ часового пояса IANA, например America/New_York . Вы не можете делать правильные изменения часового пояса только с значением -5 , потому что у вас нет всех правил, когда он переключится на -4 .

Обновить

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

Все, что вам действительно нужно для того, чтобы событие было в нужный момент, – это смещение на тот момент. Таким образом, вы можете использовать раскрывающийся список, как тот, который вы указали в своем вопросе, но я бы опустил имена зон. Это будет перечислить список смещений от UTC-12:00 до UTC+14:00 . Похоже, вы уже определили, что существует также 30-минутное и 45-минутное смещение. Вы можете проверить свои предположения здесь, если хотите.

Однако общая проблема заключается в том, что многие люди не знают, что такое смещение. Помещая список со стандартным смещением для каждого имени зоны, вы можете ввести пользователя в заблуждение, чтобы выбрать неправильное смещение. Например, они могут говорить о дате лета, которая должна попасть в восточное летнее время США (-4), но вместо этого они выбирают -5, потому что они видят «восточный». Поэтому удаление имен поможет.

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

Например, я мог бы выбрать America/New_York и выбрать время 1:00 утра 3-го ноября 2013 года. Есть два разных примера из-за перехода на спад (один в EDT на -4, а другой в EST на -5). Таким образом, ваше приложение должно будет проверить это и спросить пользователя, какой из них они имели в виду. Аналогичным образом, если я прихожу в 2:00 утра 10 марта 2013 года, ваше приложение должно сказать мне, что на этот раз в этой зоне не существует (из-за перехода на весну-вперед).

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