Comments 37
Система сильно сторонняя? Договоритесь с ними о передачи времени в unix timestamp.
ISO 8601 подходящий стандарт, вполне кросс-платформенный. Мы и в своих других подсистемах его же используем. Ну и в любом случае, они бы из-за нас ничего не стали бы менять
UFO just landed and posted this here
Ну и что? Как оно будет интерпретироваться? Вы ведь видите разницу между значением времени в момент X, которое одно для всех, и которым можно обмениваться, можно хранить, производить вычисления, и отображением, которое нужно сформировать только перед выводом конечному пользователю?
Это значит, что нужно принять соглашение между 2 и более системами, о точке отсчёта X. И не забыть что эти системы могут оказаться в разных часовых поясах. ISO это соглашение устанавливает.
Ну и нет никакой разницы в том, передавать отсчёт времени как 123456789 или 2012-12-12Т12:12:12Z+2.
Ну и нет никакой разницы в том, передавать отсчёт времени как 123456789 или 2012-12-12Т12:12:12Z+2.
Разница есть: unixtime компактнее, легче парсится, а ISO имеет больший интервал и точность.
Лёгкость парсинга компьютером, по-большому счёту — на самом деле никакое не достоинство. Гигагерцы всё равно чаще всего простаивают. А человеку посмотреть на сообщение глазами и увидеть проблему — дорогого стоит.
Не зря в какой-то момент, при появлении достаточной производительности и пропускной способности, бинарные протоколы практически ушли
Не зря в какой-то момент, при появлении достаточной производительности и пропускной способности, бинарные протоколы практически ушли
Э-э… у меня ощущение, что вы хотите мне что-то доказать, я только никак не пойму — что именно? ;)
Легкость парсинга можно не считать достоинством в случае если парсинг какой-нибудь единичный, например, файл конфигурации.
Если этот парсинг делается для каждого внешнего запроса, то рано или поздно гигагерц может не хватить и парсинг станет узким местом в масштабируемости. В этом случае бинарные протоколы более оправданы и человекочитаемостью можно пренебречь. Примеры таких современных протоколов небезызвестные Thrift и Protocol Buffers.
Если этот парсинг делается для каждого внешнего запроса, то рано или поздно гигагерц может не хватить и парсинг станет узким местом в масштабируемости. В этом случае бинарные протоколы более оправданы и человекочитаемостью можно пренебречь. Примеры таких современных протоколов небезызвестные Thrift и Protocol Buffers.
мда
умолчания всегда являются подводным камнем и когда нарвешся неизвестно
а нельзя договориться с разработчиками сторонней системы, что б время отдавали с указанием часового пояса (а лучше в UTC)?
умолчания всегда являются подводным камнем и когда нарвешся неизвестно
а нельзя договориться с разработчиками сторонней системы, что б время отдавали с указанием часового пояса (а лучше в UTC)?
Вот поэтому время нужно всегда передавать в UTC.
Я б сказал, с явным указанием TZ. А от какой именно — это уже неважно
В некоторых ситуациях может оказаться, что TZ у двух сторон будет трактоваться по-разному (кто-то не обновил tzdata, либо обновление невозможно).
Трактовать их по-разному нельзя, потому что таймзона по ISO 8601 передается в числовом виде, как разница с UTC. Поэтому обновил, не обновил… если, не важно по какой причине, клиент передал числовую тайм-зону, не соответствующую его локальному времени, то это никакими протоколами не установить. Ну все равно, как если бы у него часы неправильно шли.
Мы как-то поймали нетривиальный баг — он проявлялся у одного из клиентов в штатах, а репродьюснуть его у себя не могли. Выяснилось, что проблема была с переходом зимнее/летнее время.
Теперь мы всегда работаем с UTC датой.
Теперь мы всегда работаем с UTC датой.
Какой — нибудь вывод сделали?
Полезная статья. На всякий случай буду везде указывать 'Z'.
PS
Интересно, почему время в UTC Вы постоянно называете временем по Гринвичу?
PS
Интересно, почему время в UTC Вы постоянно называете временем по Гринвичу?
Привычка.
It is arguably the same as Coordinated Universal Time (UTC) and when this is viewed as a time zone the name Greenwich Mean Time is especially used by bodies connected with the United Kingdom, such as the BBC World Service,[1] the Royal Navy, the Met Office and others. — Wikipedia.
> В результате, есть шанс, что в версии 6 стандарта ECMA время будет таки разбираться правильно.
интересная постановка вопроса с ног на голову :)
стандарт — первичен. Если что-то не соответствует стандарту, то в этом «что-то» наблюдается косяк.
Товарищи из Mozilla — известные строители косяков и несоответствий с ECMA, и, по хорошему, должны гореть в соответствующем месте.
интересная постановка вопроса с ног на голову :)
стандарт — первичен. Если что-то не соответствует стандарту, то в этом «что-то» наблюдается косяк.
Товарищи из Mozilla — известные строители косяков и несоответствий с ECMA, и, по хорошему, должны гореть в соответствующем месте.
Не так. Первичен ISO 8601. А у ECMA получилось что получилось. Так что им и приводить в соответствие.
Причём забавно ведь то, что v8 поначалу разбирали дату ближе к ISO, а потом сломали чтобы соответствовать ECMA.
Причём забавно ведь то, что v8 поначалу разбирали дату ближе к ISO, а потом сломали чтобы соответствовать ECMA.
Ну ведь компиляторы/vm для JS должны соответствовать ECMA, а не ISO 8601. «Вассал моего вассала — не мой вассал».
Если применить принцип единственности ответственности — для добавления/определения фичи в компилятор/vm не должно быть более одной причины (одного стандарта).
Если применить принцип единственности ответственности — для добавления/определения фичи в компилятор/vm не должно быть более одной причины (одного стандарта).
Вот что написано в стандарте ECMA:
Ссылаются на 8601? Ссылаются. Говорят, что 8601 первичен? Говорят. Признают, что требуют упрощённой реализации? Признают.
А то что в Мозилла реализовали более полную версию спецификации 8601 — так они молодцы, к.м.к.
ECMAScript defines a string interchange format for date-times based upon a simplification of the ISO 8601 Extended Format. The format is as follows: YYYY-MM-DDTHH:mm:ss.sssZ
Ссылаются на 8601? Ссылаются. Говорят, что 8601 первичен? Говорят. Признают, что требуют упрощённой реализации? Признают.
А то что в Мозилла реализовали более полную версию спецификации 8601 — так они молодцы, к.м.к.
Представь ситуацию. Архитекторы спускают тебе спеку, и она очевидно идиотская: там всё на свете неоптимально, неправильно, и не соответствует здравому смыслу. Станешь ли ты говорить «архитекторы — идиоты, мы сделаем по своему!»? К каким последствиям это приведет?
С этим я не спорю. Мало того, я понимаю что именно в целях соответствия стандарту в v8 было сломано то, что раньше работало.
Но именно от этого и не легче
Но именно от этого и не легче
Станешь ли ты говорить «архитекторы — идиоты, мы сделаем по своему!»?
Сплошь и рядом сталкиваюсь с тем, что разработчики считают что в спецификации я написал полную фигню. Чаще всего мне удаётся их убедить в своей правоте. Иногда приходится признавать что да, я налажал.
Это нормально, если никто по норкам не закрывается.
Правда, цена моей ошибки в случае если заказчик системы внешний — гораздо выше. Но тут помогает предварительное согласование с разработчиками. Хотя их ещё надо суметь заставить внимательно прочесть написанное.
Ну и в багзилле на ECMAScript явно сказано, что их трактовка в версии 5.1 некорректна
Ну дык пусть вначале пофиксят стандарт, а потом реализуют изменения. Иначе это ведет к несовместимости реализаций.
Что я и написал:
После того как выйдет новый стандарт ECMA, в котором это разночтение будет исправлено и v8 обновится в соответствии с этим стандартом, нам придется это отследить и костыли убрать
Мозилловцы-то тоже могли «сломать назад» свою реализацию, пока не починят спеку.
Готов поспорить, они это ни в жизни не сделают.
Готов поспорить, они это ни в жизни не сделают.
Мда, неприятная и глупая ситуация, и что нужно править — очевидно, но, честно говоря, вариант ECMA логичнее. Просто потому что локальных времен много, а UTC — одно, и шансов ограсте проблем с ним меньше. И вообще — чем меньше точек в системе, где используется локальное время, тем меньше шансов для ошибок. В идеале — преобразовывать в локаль надо непосредственно перед выводом человеку, а после ввода (от человека, опять же) — сразу в UTC. А уж между системами обмениваться в локальном времени… брр.
В данном конкретном случае обе системы живут по одному времени, так что проблем от того, что они не присылают в UTC, не должно было быть.
Ну, и вариант ECMA никак не логичнее, потому что он противоречит стандарту более высокого уровня. Именно поэтому именно стандарт ECMA и будет приводиться в соответствие ISO.
Ну, и вариант ECMA никак не логичнее, потому что он противоречит стандарту более высокого уровня. Именно поэтому именно стандарт ECMA и будет приводиться в соответствие ISO.
Sign up to leave a comment.
ISO 8601 и ECMAScript — головная боль от разночтения стандартов