Когда я использую
на моем ящике ArchLinux, системное время ведет себя хорошо:
> date
Tue Oct 23 17:10:34 TAI 2018
> date -d @1483228827
Sun Jan 1 00:00:00 UTC 2017
> date -d @1483228826
Sat Dec 31 23:59:60 UTC 2016
> date -d @1483228825
Sat Dec 31 23:59:59 UTC 2016
но: JavaScript не делает:
-arne
так они внедрили специальные меры, которые не позволяют JavaScript использовать системную информацию о зоне? если да: как мы можем это изменить?
Нет, они просто нет делают что-то особенное, включая високосные секунды.
но: они приняли активные контрмеры против таких людей, как я, чьи системные часы "знают" эти 27 "прыжковых" секунд ... могу ли я как-нибудь отключить эти контрмеры? или мой javascript плохой?
На чем вы основываете свое предположение об «активных контрмерах»? Вы проверили, что делают другие языки?
гул ... да ... C работает нормально (или что там написано в date) ... см. выше ... область серого фона ...
Вы можете дать рекомендацию TC39, который контролирует ECMA-262, и попросить разработчиков принять ее. Но дополнительные секунды можно игнорировать, если вы не пытаетесь их представить или не имеете значения времени, которое их включает, они не нужны для общих функций даты и времени. В этом случае вы можете включить базу данных значений и дат, чтобы их можно было применить.
Системное время UNIXoid может представлять дополнительные секунды ... поэтому JavaScript просто должен использовать эти функции (например, localtime_r (с переменной среды TZ) и gmtime_r) ... это было бы подходящим местом? github.com/tc39/ecma262/issues/new



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


Объект JavaScript Date специально придерживается концепции Время Unix (хотя и с более высокой точностью). Это часть спецификации POSIX, поэтому иногда ее называют «временем POSIX». Он не считает дополнительные секунды, а предполагает, что каждый день имел ровно 86 400 секунд. Вы можете прочитать об этом в раздел 20.3.1.1 текущей спецификации ECMAScript, где говорится:
Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC. In time values leap seconds are ignored. It is assumed that there are exactly 86,400,000 milliseconds per day.
В этом отношении JavaScript не уникален. Это то, что делает подавляющее большинство других языков, включая Python, Ruby, .NET, типичную реализацию time_t в C и многие другие.
Поскольку вы изменили свою систему для отслеживания TAI вместо UTC, и в вашей системе есть реализация таблицы дополнительных секунд, которую понимает команда date, то в вашей системе time_t не является временной меткой Unix, а скорее Вариант на основе TAI, маскирующимся под метка времени Unix. Тот факт, что команда date и другие базовые функции распознают это, не означает, что это распространяется на все платформы и среды выполнения на вашем компьютере.
Дело в том, что непредсказуемость дополнительных секунд затрудняет работу с ними в API. Обычно нельзя передавать временные метки, которые требуют правильной интерпретации таблиц дополнительных секунд, и ожидать, что одна система будет интерпретировать их так же, как другая. Например, хотя ваша временная метка 1483228826 в вашей системе является 2017-01-01T00:00:00Z, она будет интерпретироваться как 2017-01-01T00:00:26Z в системах на основе POSIX или системах без таблиц дополнительной секунды. Так что они не портативны. Даже в системах с полностью обновленными таблицами неизвестно, что эти таблицы будут содержать в будущем (после 6-месячного периода объявления IERS), поэтому я не могу создать метку времени в будущем без риска того, что она может в конечном итоге измениться.
Чтобы было ясно - для поддержки дополнительных секунд в языке программирования реализация должна делать все возможное и идти на компромиссы, которые не всегда приемлемы. Хотя есть исключения, общая позиция заключается в том, чтобы не поддерживать их - не из-за каких-либо подрывных действий или активных контрмер, а потому, что поддерживать их должным образом намного, намного труднее.
Тем не менее, у вас есть надежда, если вы действительно заботитесь о дополнительных секундах в JavaScript. Вы можете добавить свои мысли к TC39 Временное предложение (из которых я один из чемпионов). Это не изменит поведения объекта Date - оно запекалось десятилетиями. Но мы разрабатываем новый набор стандартных объектов для даты и времени в JavaScript и будем рады вашим отзывам и участию. В выпуске # 54 есть поток, в котором мы рассматривали различные способы, которыми могут быть задействованы дополнительные секунды. На данный момент мы не особо задумывались о системах на основе TAI. Если это область, в которой у вас есть опыт, пожалуйста, поделитесь там своими мыслями. Имейте в виду, что нам нужно уравновесить это с общими потребностями сообщества, но мы хотели бы узнать ваше мнение. Спасибо!
1. приложение, работающее на нескольких компьютерах, должно использовать метки времени, которые имеют одно и то же значение (например, (aa) «секунды TAI с начала 1970 г., но не дополнительные секунды» или (bb) «секунды TAI с начала 1970 г.») ). 2. (аа) если системные часы не знают дополнительных секунд (это легко узнать ... нужно просто попросить систему сломать 1483228826 с помощью gmtime () и посмотреть на секунды), тогда приложение может отказаться запускать или использовать (прозрачно для пользователя) более сложный код.
1. Если кто-то скажет, что мы встретимся в 1856149396 TAI секундах после начала 1970 года, то, насколько мы можем судить сегодня, это будет «2028-10-26T05: 02: 49UTC». Но из-за дополнительных секунд эта строка времени UTC может измениться на «2028-10-26T05: 02: 39UTC», пока не приблизится время встречи. 2. если кто-то действительно хочет встретиться именно в «2028-10-26T05: 02: 49UTC», он / она должен сохранить это время не как «секунды TAI с некоторого момента времени», потому что UTC просто не поддерживает это, поскольку в нем есть аномалии в некоторые (возможно, даже неизвестные и непредсказуемые) моменты времени.
Я также прокомментировал эту проблему №54: github.com/tc39/proposal-temporal/issues/…
Всегда есть спецификация языка, ECMA-262: "Время измеряется в ECMAScript в миллисекундах с 1 января 1970 года по всемирному координированному времени. Во времени значения дополнительных секунд игнорируются. Предполагается, что в день ровно 86 400 000 миллисекунд."