Станешь ли ты говорить «архитекторы — идиоты, мы сделаем по своему!»?
Сплошь и рядом сталкиваюсь с тем, что разработчики считают что в спецификации я написал полную фигню. Чаще всего мне удаётся их убедить в своей правоте. Иногда приходится признавать что да, я налажал.
Это нормально, если никто по норкам не закрывается.
Правда, цена моей ошибки в случае если заказчик системы внешний — гораздо выше. Но тут помогает предварительное согласование с разработчиками. Хотя их ещё надо суметь заставить внимательно прочесть написанное.
После того как выйдет новый стандарт ECMA, в котором это разночтение будет исправлено и v8 обновится в соответствии с этим стандартом, нам придется это отследить и костыли убрать
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 — так они молодцы, к.м.к.
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.
Лёгкость парсинга компьютером, по-большому счёту — на самом деле никакое не достоинство. Гигагерцы всё равно чаще всего простаивают. А человеку посмотреть на сообщение глазами и увидеть проблему — дорогого стоит.
Не зря в какой-то момент, при появлении достаточной производительности и пропускной способности, бинарные протоколы практически ушли
Это значит, что нужно принять соглашение между 2 и более системами, о точке отсчёта X. И не забыть что эти системы могут оказаться в разных часовых поясах. ISO это соглашение устанавливает.
Ну и нет никакой разницы в том, передавать отсчёт времени как 123456789 или 2012-12-12Т12:12:12Z+2.
ISO 8601 подходящий стандарт, вполне кросс-платформенный. Мы и в своих других подсистемах его же используем. Ну и в любом случае, они бы из-за нас ничего не стали бы менять
Ни разу ещё не встречал ситуации, когда SMART хоть о чём-нибудь предупредил бы. Опыт, конечно, небольшой, всего порядка 200 винчестеров в течение 1,5 лет с выходом из строя примерно 1 винчестера в месяц. Но тут урок в том, что не стоит использовать бытовые винчестеры в нагруженных системах. Конечно, и винчестеры менялись по гарантии, и RAID помогал, но всё равно, потери времени чего-то стоят.
Вообще-то, не первое. Ещё пару лет назад использовал TripJane. На руках были обратные билеты С-Ф — Мск с фиксированной датой и была необходимость задержаться ещё на 2 недели. Сервис реально помог. Было реализовано как приложение в facebook.
Там концепция для меня даже лучше. Чистая синхронизация без необходимости в дядином облаке. Поскорей бы сделали синхронизацию произвольных папок — сразу перейду.
Сплошь и рядом сталкиваюсь с тем, что разработчики считают что в спецификации я написал полную фигню. Чаще всего мне удаётся их убедить в своей правоте. Иногда приходится признавать что да, я налажал.
Это нормально, если никто по норкам не закрывается.
Правда, цена моей ошибки в случае если заказчик системы внешний — гораздо выше. Но тут помогает предварительное согласование с разработчиками. Хотя их ещё надо суметь заставить внимательно прочесть написанное.
Но именно от этого и не легче
Ссылаются на 8601? Ссылаются. Говорят, что 8601 первичен? Говорят. Признают, что требуют упрощённой реализации? Признают.
А то что в Мозилла реализовали более полную версию спецификации 8601 — так они молодцы, к.м.к.
Причём забавно ведь то, что v8 поначалу разбирали дату ближе к ISO, а потом сломали чтобы соответствовать ECMA.
Не зря в какой-то момент, при появлении достаточной производительности и пропускной способности, бинарные протоколы практически ушли
Ну и нет никакой разницы в том, передавать отсчёт времени как 123456789 или 2012-12-12Т12:12:12Z+2.
Сейчас, похоже, с ними всё.