Я знаю, что это устаревает, надеюсь, что нижеприведенное, по крайней мере, подстегнет разговоры и идеи.
Итак, в основе этого вопроса, на мой взгляд, лежит проблема с ISO 8601, он не может нести необходимую информацию, чтобы помочь в переходе на летнее время.
Некоторое время назад я столкнулся с подобной проблемой и провел много «конструктивных» бесед с коллегами о том, как лучше всего решить проблему даты, записанной внутри летнего времени, но просматриваемой из часового пояса без перехода на летнее время ... мы всегда продолжали возвращаться к ISO 8601 будучи властелином, всемогущим в решении проблемы переноса даты и времени, но он так и не решил проблему перехода на летнее время.
Вывод был похож на то, что в конечном итоге решают многие люди, а именно: использовать ISO 8601 для даты и времени со смещением (даже если это было бесполезно), а затем предоставить дополнительную часть данных, чтобы указать часовой пояс, в котором дата и время принадлежало. Это позволило рендерингу на стороне клиента предоставить часовой пояс вместе с ISO 8601, чтобы дать фактическую правильную дату и время независимо от часового пояса.
Это было не то место, где я хотел это оставить ... на самом деле я был одним из немногих в обсуждениях, которые продолжали ковырять дыры в часовых поясах в ISO 8601, когда другие были убеждены, что смещения достаточно. Точно так же, как вы обнаружили, он не позволяет учитывать часовой пояс или точное преобразование в другие часовые пояса, и поэтому я счел ISO 8601 недопустимыми датой и временем с транспортным форматом часового пояса.
Нижеследующее частично является шуткой, но это также серьезно, если вы считаете, что этого достаточно, чтобы просто работать ... IOS 8601 имеет строгий формат, которому нужно следовать, так же, как и это, и когда вы следуете ему правильно, он просто работает без ошибок ...
Эта страница содержит подробную информацию о формате, а также несколько глупых шуток о планетарной поддержке часовых поясов. https://github.com/Gitapedia/AltSO-8601
У меня также есть расширенный класс Carbon PHP, который поддерживает синтаксический анализ и преобразование формата Altso 8601. https://packagist.org/packages/mossengine/alteredcarbon Этот пакет было бы лучше плагин к пакету Carbon, но расширенного класса было достаточно, чтобы хотя бы продемонстрировать концепцию.
Похоже, что можно было бы поработать над улучшением формата ISO 8601 с пересмотром, но я не могу ждать так долго и чувствую, что смещение бесполезно и может быть заменено часовым поясом, и зачем нам нужны все двоеточия, тире, Ts и Zs, когда мы можем просто объединить дату и время вместе, и они все еще читабельны и меньше, чтобы учесть дополнительные байты, необходимые для предоставления часового пояса.
Следующим шагом будет рассмотрение (если таковая существует) поддержки часовых поясов коротких имен или их изобретение, чтобы формат Altso 8601 мог передавать меньшие объемы данных с более глубоким пониманием даты и времени (особенно часового пояса).
person
Brendon Moss
schedule
27.12.2018
