ISO 8601 и ECMAScript — головная боль от разночтения стандартов

[alienator]

Система сильно сторонняя? Договоритесь с ними о передачи времени в unix timestamp.

[pred8or]

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

[alienator]

Ну и что? Как оно будет интерпретироваться? Вы ведь видите разницу между значением времени в момент X, которое одно для всех, и которым можно обмениваться, можно хранить, производить вычисления, и отображением, которое нужно сформировать только перед выводом конечному пользователю?

[pred8or]

Это значит, что нужно принять соглашение между 2 и более системами, о точке отсчёта X. И не забыть что эти системы могут оказаться в разных часовых поясах. ISO это соглашение устанавливает.

Ну и нет никакой разницы в том, передавать отсчёт времени как 123456789 или 2012-12-12Т12:12:12Z+2.

[alienator]

Разница есть: unixtime компактнее, легче парсится, а ISO имеет больший интервал и точность.

[pred8or]

Лёгкость парсинга компьютером, по-большому счёту — на самом деле никакое не достоинство. Гигагерцы всё равно чаще всего простаивают. А человеку посмотреть на сообщение глазами и увидеть проблему — дорогого стоит.

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

[alienator]

Э-э… у меня ощущение, что вы хотите мне что-то доказать, я только никак не пойму — что именно? ;)

[pred8or]

Не, ничего такого, просто комментарии по ходу дела.

[zerodivisi0n]

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

Если этот парсинг делается для каждого внешнего запроса, то рано или поздно гигагерц может не хватить и парсинг станет узким местом в масштабируемости. В этом случае бинарные протоколы более оправданы и человекочитаемостью можно пренебречь. Примеры таких современных протоколов небезызвестные Thrift и Protocol Buffers.

[pred8or]

Я ж и говорю, практически ушли. Всему есть своё место.

Но если есть текстовый протокол, то передавать бинарные данные такие как unixtime — странно по многим причинам.

[onk]

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

а нельзя договориться с разработчиками сторонней системы, что б время отдавали с указанием часового пояса (а лучше в UTC)?

[Obramko]

Вот поэтому время нужно всегда передавать в UTC.

[pred8or]

Я б сказал, с явным указанием TZ. А от какой именно — это уже неважно

[Obramko]

В некоторых ситуациях может оказаться, что TZ у двух сторон будет трактоваться по-разному (кто-то не обновил tzdata, либо обновление невозможно).

[alienator]

Трактовать их по-разному нельзя, потому что таймзона по ISO 8601 передается в числовом виде, как разница с UTC. Поэтому обновил, не обновил… если, не важно по какой причине, клиент передал числовую тайм-зону, не соответствующую его локальному времени, то это никакими протоколами не установить. Ну все равно, как если бы у него часы неправильно шли.

[AlDev]

Мы как-то поймали нетривиальный баг — он проявлялся у одного из клиентов в штатах, а репродьюснуть его у себя не могли. Выяснилось, что проблема была с переходом зимнее/летнее время.
Теперь мы всегда работаем с UTC датой.

[seriyPS]

Какой — нибудь вывод сделали?

[pred8or]

Ну, какой тут может быть вывод… грабли разложены везде

[Pilat]

Полезная статья. На всякий случай буду везде указывать 'Z'.

PS
Интересно, почему время в UTC Вы постоянно называете временем по Гринвичу?

[pred8or]

Привычка.

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.

[olegchir]

> В результате, есть шанс, что в версии 6 стандарта ECMA время будет таки разбираться правильно.

интересная постановка вопроса с ног на голову :)

стандарт — первичен. Если что-то не соответствует стандарту, то в этом «что-то» наблюдается косяк.

Товарищи из Mozilla — известные строители косяков и несоответствий с ECMA, и, по хорошему, должны гореть в соответствующем месте.

[pred8or]

Не так. Первичен ISO 8601. А у ECMA получилось что получилось. Так что им и приводить в соответствие.

Причём забавно ведь то, что v8 поначалу разбирали дату ближе к ISO, а потом сломали чтобы соответствовать ECMA.

[olegchir]

Ну ведь компиляторы/vm для JS должны соответствовать ECMA, а не ISO 8601. «Вассал моего вассала — не мой вассал».

Если применить принцип единственности ответственности — для добавления/определения фичи в компилятор/vm не должно быть более одной причины (одного стандарта).

[pred8or]

Вот что написано в стандарте ECMA:

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 — так они молодцы, к.м.к.

[olegchir]

Представь ситуацию. Архитекторы спускают тебе спеку, и она очевидно идиотская: там всё на свете неоптимально, неправильно, и не соответствует здравому смыслу. Станешь ли ты говорить «архитекторы — идиоты, мы сделаем по своему!»? К каким последствиям это приведет?

[pred8or]

С этим я не спорю. Мало того, я понимаю что именно в целях соответствия стандарту в v8 было сломано то, что раньше работало.

Но именно от этого и не легче

[pred8or]

Станешь ли ты говорить «архитекторы — идиоты, мы сделаем по своему!»?

Сплошь и рядом сталкиваюсь с тем, что разработчики считают что в спецификации я написал полную фигню. Чаще всего мне удаётся их убедить в своей правоте. Иногда приходится признавать что да, я налажал.

Это нормально, если никто по норкам не закрывается.

Правда, цена моей ошибки в случае если заказчик системы внешний — гораздо выше. Но тут помогает предварительное согласование с разработчиками. Хотя их ещё надо суметь заставить внимательно прочесть написанное.

[pred8or]

Ну и в багзилле на ECMAScript явно сказано, что их трактовка в версии 5.1 некорректна

[olegchir]

Ну дык пусть вначале пофиксят стандарт, а потом реализуют изменения. Иначе это ведет к несовместимости реализаций.

[pred8or]

Что я и написал:

После того как выйдет новый стандарт ECMA, в котором это разночтение будет исправлено и v8 обновится в соответствии с этим стандартом, нам придется это отследить и костыли убрать

[olegchir]

Мозилловцы-то тоже могли «сломать назад» свою реализацию, пока не починят спеку.

Готов поспорить, они это ни в жизни не сделают.

[pred8or]

Хорошо ли, плохо ли, но Мозилла и не говорит, что у них ECMA. В данном конкретном случае я считаю что это хорошо.

А вообще, неплохо бы вспомнить когда и почему Microsoft протащила свою спецификацию JScript именно через европейскую организацию по стандартизации.

[pred8or]

Похоже я немного наврал. Википедия говорит, что инициатива в том случае шла вовсе даже от Netscape. Хотя у меня немного другие воспоминания. Но нам же не дано знать всей правды :-)

[dikarik]

Мда, неприятная и глупая ситуация, и что нужно править — очевидно, но, честно говоря, вариант ECMA логичнее. Просто потому что локальных времен много, а UTC — одно, и шансов ограсте проблем с ним меньше. И вообще — чем меньше точек в системе, где используется локальное время, тем меньше шансов для ошибок. В идеале — преобразовывать в локаль надо непосредственно перед выводом человеку, а после ввода (от человека, опять же) — сразу в UTC. А уж между системами обмениваться в локальном времени… брр.

[pred8or]

В данном конкретном случае обе системы живут по одному времени, так что проблем от того, что они не присылают в UTC, не должно было быть.

Ну, и вариант ECMA никак не логичнее, потому что он противоречит стандарту более высокого уровня. Именно поэтому именно стандарт ECMA и будет приводиться в соответствие ISO.

[dikarik]

Ну да, что к чему приводить — очевидно. Но вот ISO-стандарт в этом месте явно неудачен.