31.12.2016 23:59:60 — 2016 год продлится на секунду дольше

 
1 2 3 4 5
?? Lenta.ru : Новости #29.12.2016 16:46
+
-
edit
 

Lenta.ru : Новости
Guest

гость
Сообщение было перенесено из темы Дайджест от декабря 2016г.

2016 год продлится на секунду дольше

По всемирному координированному времени (UTC) 31 декабря 2016 года произойдет добавление одной секунды. По Гринвичу 31 декабря 2016 года после 23:59:59 наступит не 1 января 2017 года (со временем 00:00:00), а 23:59:60. Такое решение приняла Международная служба вращения Земли.

// Источник: https://lenta.ru/news/2016/12/29/wait_a_second/

 

+
-
edit
 

Balancer

администратор
★★★★★
Linux в лице Ubuntu так и не готов к сабжу.

31.12.2016 23:59:59 = 1483217999
01.01.2017 00:00:00 = 1483218000
 44

ssb

новичок

Balancer> Linux в лице Ubuntu так и не готов к сабжу.
Balancer> 31.12.2016 23:59:59 = 1483217999
Balancer> 01.01.2017 00:00:00 = 1483218000

Linux, Ubuntu, и проч. тут абсолютно ни при чём --

(1) leap second будет не по Москве (1483218000), а по UTC (1483228800)
(2) В шкале времени UNIX никак это отражено не будет — не предусмотрено by design. И даже задним числом утилита 'date' никогда не признается, что указанный момент времени был 23:59:60 а не 00:00:00. -EWONTFIX :)

И, кстати, штатный метод учёта leap second в *никсах это NTP демон — он, получив информацию о leap second из сети, выставляет соответствующий флаг через системный вызов.

Мои сервера "к бою" готовы:
$ ntpq -crv
...
processor="i686", system="Linux/4.xx.xx", leap=01,
stratum=2, precision=-21, rootdelay=4.994, rootdisp=18.759,
refid=xx.xx.xx.xx,
...
$
 




А ровно в полночь по Гринвичу, карета превратится в тыкву, ядро вставит секунду и оповестит об этом всех читателей syslog, типа вот так:
Clock: inserting leap second 23:59:60 UTC
 


Технически в ядре Linux это делается удлинением последней секунды. Далеко не всех этот бардак конечно устраивает. Кто-то жалуется, кто-то активно агитирует то за одно ("високосный час" раз в тысячу лет вместо секунды раз в полтора года), то за другое (вообще отменить).


А вот в корпорации Добра собрались решить этот вопрос "за всех", хотят этого "все" или нет, раз: предложили своё решение (leap smear) (на мой взгляд, отвратительное — предлагают размазать лишнюю секунду на целый день). И два: доложили о том, что их публичные NTP сервера будут работать по этой технологии.
 50.050.0
Это сообщение редактировалось 31.12.2016 в 16:15

Balancer

администратор
★★★★★
ssb> (1) leap second будет не по Москве (1483218000), а по UTC (1483228800)

Да, это я протормозил :) Один фиг, ничего не меняется.

31.12.2016 23:59:59 UTC = 1483228799
01.01.2017 00:00:00 UTC = 1483228800

ssb> (2) В шкале времени UNIX никак это отражено не будет — не предусмотрено by design.

Как это не предусмотрено, когда это число секунд с 01.01.1970 00:00:00 UTC. Если год на секунду дольше длится, то и UNIXTIME на секунду больше должен быть. Иначе это уже не число секунд с заданного момента, а какая-то фигня :)
 44
+
+2
-
edit
 

ssb

новичок

ssb>> (2) В шкале времени UNIX никак это отражено не будет — не предусмотрено by design.
Balancer> Как это не предусмотрено, когда это число секунд с 01.01.1970 00:00:00 UTC.
Не, не так, см: определение.

Balancer> Если год на секунду дольше длится, то и UNIXTIME на секунду больше должен быть. Иначе это уже не число секунд с заданного момента, а какая-то фигня :)

... а так, собственно, оно и есть. )

"Open Group Base Specifications Rationale":
Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences. Broken-down POSIX time is therefore not necessarily UTC, despite its appearance.
 
Отсюда.

Выделенное италиком выше — :alco::kos::cannabis: ... так и живём.
 50.050.0

Balancer

администратор
★★★★★
ssb> Не, не так, см

Блин. Ты разрушил мой фундамент. Я-то думал, что это реальный абсолютный базис, а это оказалась фигня на постном масле :) Печально... Ну, ждём, пока, наконец, введут шкалу абсолютного времени...
 44
ssb> Технически в ядре Linux это делается удлинением последней секунды. Далеко не всех этот бардак конечно устраивает. Кто-то жалуется, кто-то активно агитирует то за одно ("високосный час" раз в тысячу лет вместо секунды раз в полтора года), то за другое (вообще отменить).
ssb> А вот в корпорации Добра собрались решить этот вопрос "за всех", хотят этого "все" или нет, раз: предложили своё решение (leap smear) (на мой взгляд, отвратительное — предлагают размазать лишнюю секунду на целый день).

А представьте как мы мучались когда время дважды в год дергали на целый час!
 33.033.0
LT Bredonosec #01.01.2017 15:02  @TEvg-2#31.12.2016 22:37
+
-
edit
 
TEvg-2> А представьте как мы мучались когда время дважды в год дергали на целый час!

а в европах и сейчас дергают. И ничего.
Voeneuch, учи физику, манажор ))  26.026.0
+
-
edit
 

Balancer

администратор
★★★★★
TEvg-2> А представьте как мы мучались когда время дважды в год дергали на целый час!

По сравнению с сабжем это такая же проблема, как необходимость обуваться при выходе на улицу против отсутствия ног вообще :)

Менять часовой пояс пару раз в год — вообще не проблема по сравнению с отсутствием реального абсолютного времени.
 44
RU Balancer #01.01.2017 15:53  @Bredonosec#01.01.2017 15:02
+
-
edit
 

Balancer

администратор
★★★★★
Bredonosec> а в европах и сейчас дергают. И ничего.

Как и в США, Канаде... и ещё в более чем 80, ЕМНИП, странах :)
 44
+
-
edit
 

Monya

опытный

Bredonosec>> а в европах и сейчас дергают. И ничего.
Balancer> Как и в США, Канаде... и ещё в более чем 80, ЕМНИП, странах :)
Дык практически все современные микропроцессорные системы, которые с реальным временем связаны имеют опцию автоматического перехода на летнее/зимнее время (причем полностью настраиваемую). Так что это уже не проблема. А то было, канешно, кондовые вычислители и контроллеры приходилось ручками переставлять. Причем, ЧСХ, для этого приходилось выходить на работу в выходной день :( .
А вот отсутствие абсолютного времени - таки да, проблем-с :(
 49.0.2623.11249.0.2623.112
+
-1
-
edit
 
Balancer> Менять часовой пояс пару раз в год — вообще не проблема по сравнению с отсутствием реального абсолютного времени.

Подвод часов на 1 сек - это усраться какая сложная проблема, по сравнению с дерганием часов на целый час дважды в год?
 33.033.0
RU TEvg-2 #01.01.2017 22:23  @Bredonosec#01.01.2017 15:02
+
+1
-
edit
 
TEvg-2>> А представьте как мы мучались когда время дважды в год дергали на целый час!
Bredonosec> а в европах и сейчас дергают. И ничего.

В европе и родитель 1 и родитель 2 друг дружку в зад жарят. Мало ли что бывает в европе.
 33.033.0
+
-1
-
edit
 
Monya> Дык практически все современные микропроцессорные системы, которые с реальным временем связаны имеют опцию автоматического перехода на летнее/зимнее время (причем полностью настраиваемую). Так что это уже не проблема. А то было, канешно, кондовые вычислители и контроллеры приходилось ручками переставлять. Причем, ЧСХ, для этого приходилось выходить на работу в выходной день :(

Т.е. задал командой/мышкой/кнопкой время, выйдя для этого на работу и трава не расти? Никаких проблем больше нет?

А как это на техпроцессы повлияет? Никак?
Ну вот у нас на АСКУЭ при этом возникала неучтенка с электричеством. В том числе криво вычислялась нагрузка и отправлялась диспечеру энергосистемы. И приходилось прикрывать срам рукой - составлять и подписывать актик, мол де время переведено, поэтому той лаже что накорябала машина не верить, а верить этой бумажке.
А учет угля делала уже моя прога, поэтому там косяков таких не было. Зато мне пришлось следить, чтобы внутри никакое время, спаси Аллах, не переводилось. Чтобы внутри время было абсолютное. И чтобы все считалось в абсолюте. А коректировка шла уже при выводе информации, при генерации отчетов. Мне пришлось изобретать индикацию (шкалы, графики и проч проч проч) в трех вариантах - нормальную, с укоцанным часом и повторным часом, да так чтобы можно было четко понять, когда произошло событие - в основной час или в лишний час. Все это надо было отлаживать. Пустячок правда?
А ещё надо было отлаживать работу защит и регуляторов. К примеру допускается кратковременный перегруз девайса на сколько-то процентов и сколько-то секунд. Больше перегруз - меньше допустимый период - есть табличка соответсвия. Если режим не восстановился - аварийно останавливаемся. А теперь представим что где-то в мозгах системы перевелось время. Как будет работать девайс? Да ведь там не одно устройство. Там 100500 устройств хитрожопым образом связанных. И дай Бог ихнюю логику и без перевода времени правильно сделать. А сделать с переводом времени? А главное всю эту байду проверить. А смоделировать можно было только отдельные компоненты системы. Вся система моделированию не поддавалась. Испытать её можно было только вживую. Весело? И да, конечно надо было выходить на работу (ночью, ведь ночью время переводится) и смотреть как бы чего не вышло.
А железнодорожники при переводах времени должны корректировать туда-сюда свой график. Ведь если поезд должен поехать в 8:00 хоть по новому времени, хоть по старому - то он должен поехать. Как он поедет, если ему сократили время в пути на час? Или лишнее дали? Вот такой херней и приходится заниматься. И увязывать это всё с смежниками. Офисный хомячок ночью спит, а работяги при переводе вынуждены работать лишний час. Мы его оплачивать не будем или как? А автоматизированная бухгалтерия сама это правильно посчитает? Если посчитает - значит там где-то уже сидел программист, кодил эту ситуацию, и ругался непотребными словами.

Если у вас Моня в воздухе висит 100500 дронов, а время перевелось в наземной диспечерской системе и в самих дронах, вы уверены, что при этом никто не упадет?

Слава Медведу, избавившего нас от тупой и нелепой работы!
Больше всего бесит именно тупая и нелепая работа.
Если там где-то есть гравитация, то приходится с этим считаться как с данностью. Но как можно терпеть, когда какой-то сын собаки придумал дергать часы взад и вперед?
 33.033.0
+
+1
-
edit
 

Mishka

модератор
★★★

TEvg-2> Подвод часов на 1 сек - это усраться какая сложная проблема, по сравнению с дерганием часов на целый час дважды в год?
Дёрганье на час не меняет UTC алгоритмы. Просто локальное время отображается по другому. А вот лишняя секунда никак не учитывается, т.е. в твоих всяких алгоритмах, когда надо померять временной интервал для каких-то вещей, эта секунда участвовать не будет, если переход попал в интервал. Вот представь, что запустил ты ракету 31 декабря 2016 в 23:59:00 по UTC, а движок второй ступени должен запуститься ровно через 70 секунд в 00:00:10. И вот ты берёшь ты в программке время +70. И POSIX система тебе говорит, что в 00:00:10 надо запустить, а наземная станция видит включение со сдвигом на секунду. Поскольку её бортовое время 00:00:09 — она соединена по NTP, а бортовая — нет.
 50.050.0
+
-2
-
edit
 
Mishka> Дёрганье на час не меняет UTC алгоритмы. Просто локальное время отображается по другому. А вот лишняя секунда никак не учитывается, т.е. в твоих всяких алгоритмах, когда надо померять временной интервал для каких-то вещей, эта секунда участвовать не будет, если переход попал в интервал. Вот представь, что запустил ты ракету 31 декабря 2016 в 23:59:00 по UTC, а движок второй ступени должен запуститься ровно через 70 секунд в 00:00:10. И вот ты берёшь ты в программке время +70. И POSIX система тебе говорит, что в 00:00:10 надо запустить, а наземная станция видит включение со сдвигом на секунду. Поскольку её бортовое время 00:00:09 — она соединена по NTP, а бортовая — нет.

Ну вот сдвиг на 1 секунду приносит неприятности, а представь какие неприятности принесет сдвиг времени на час!

А секундными ошибками приходится заниматься полюбасику. Дело в том что часы постоянно уходят, сбиваются, приходится их корректировать. Обычно на 1 секунду.

А вот где эта 1-секундная ошибка неприемлима - там городи свою систему абсолютного времени. Всего-то.
Ввиду часовых дерганий нам же приходится оперировать абсолютным временем. Вот и сделай суперабсолютное время. А UTC будет относительно него подвирать - это ты уже учтешь програмно.

Во всяком случае ситуаций где критична 1 секунда в 100500 раз меньше, чем ситуаций где критична ошибка в один час. Да и кроме того 1 секундная ошибка случается 1 раз в сколько-то лет и ту же ракету ты можешь тупо не запускать в это время. А дергание в час - два раза в год.
 33.033.0
LT Bredonosec #02.01.2017 02:24  @TEvg-2#01.01.2017 22:23
+
+2
-
edit
 
TEvg-2> В европе и родитель 1 и родитель 2 друг дружку в зад жарят. Мало ли что бывает в европе.
женя, ты всерьёз не понимаешь разницу между переключением отображения времени при выставленной схеме "timezone UTC +3 winter time", и переводом самого времени?
Если какие-то процессы на сервах требуют оценки быстродействия, то перескок на сек назад или повтор секунды будут означать многократное деление на ноль или получение отрицательных величин там, где подобная ошибка не описана, то это будет с немалой долей вероятности означать вылет процесса. Если некие банковские или биржевые программы счиатют рост-падение индексов, то опять же, возможны деления на ноль или отрицательные значения там, где подобное никто не описывал.
И т.д. и т.п.
И искать, в какой из миллионов программ что может переглючить с непредсказуемыми последствиями - такой геморрой, что пресловутая иголка в стоге сена - просто образец простоты.
Voeneuch, учи физику, манажор ))  26.026.0
+
+1
-
edit
 

Balancer

администратор
★★★★★
TEvg-2>> Подвод часов на 1 сек - это усраться какая сложная проблема
Mishka> Дёрганье на час не меняет UTC алгоритмы.

Он не поймёт :)
 55.0.2883.8755.0.2883.87

Monya

опытный

TEvg-2> А как это на техпроцессы повлияет? Никак?
Никак. Хорошая Scada все равно все считает в абсолютном времени. Смена времени повлияет только на метки времени в архивах.
TEvg-2> Ну вот у нас на АСКУЭ при этом возникала неучтенка с электричеством.
Это да. У нас тоже газа получалось больше/меньше за сутки в зависимости от времени перевода. Но, по сути, проблемы чисто бухгалтерские. Проблемы индейцев бухгалтеров шерифа автоматчиков мало трогают :)
TEvg-2> А ещё надо было отлаживать работу защит и регуляторов. К примеру допускается кратковременный перегруз девайса на сколько-то процентов и сколько-то секунд. Больше перегруз - меньше допустимый период - есть табличка соответсвия. Если режим не восстановился - аварийно останавливаемся. А теперь представим что где-то в мозгах системы перевелось время. Как будет работать девайс? Да ведь там не одно устройство. Там 100500 устройств хитрожопым образом связанных. И дай Бог ихнюю логику и без перевода времени правильно сделать. А сделать с переводом времени? А главное всю эту байду проверить. А смоделировать можно было только отдельные компоненты системы. Вся система моделированию не поддавалась. Испытать её можно было только вживую. Весело? И да, конечно надо было выходить на работу (ночью, ведь ночью время переводится) и смотреть как бы чего не вышло.
А вот это свидетельствует о кривости управляющего софта. Да, такие проблемы были. Но в современных Scada от них, слава богу избавились. Насколько пользовал последние версии ClearScada, CitectSCADA, SCX. Wizcon - там уже таких проблем нет. Архивация никак не связана с проблемами управления. Управление ведется в привязке к абсолютному времени и системе наплевать на перевод относительного.
TEvg-2> А железнодорожники при переводах времени должны корректировать туда-сюда свой график. Ведь если поезд должен поехать в 8:00 хоть по новому времени, хоть по старому - то он должен поехать. Как он поедет, если ему сократили время в пути на час? Или лишнее дали? Вот такой херней и приходится заниматься. И увязывать это всё с смежниками. Офисный хомячок ночью спит, а работяги при переводе вынуждены работать лишний час. Мы его оплачивать не будем или как? А автоматизированная бухгалтерия сама это правильно посчитает? Если посчитает - значит там где-то уже сидел программист, кодил эту ситуацию, и ругался непотребными словами.
Это да. Особенно про хомячков верно. Я тоже незлым тихим словом это вспоминал, когда мне на 20-30 объектах в поле надо было время поменять. Причем на ряде контроллеров параноидальная система безопасности позволяла менять время только непосредственно (удаленно - шиш там). С учетом расстояний и "легкодоступности" объектов - еще та песня.
TEvg-2> Если у вас Моня в воздухе висит 100500 дронов, а время перевелось в наземной диспечерской системе и в самих дронах, вы уверены, что при этом никто не упадет?
Если синхронно и при отлаженном софте - то вряд-ли. Но... - это конечно в идеале. В реале корявость софта, несинхронность смены времени и человеческий фактор свое черное дело сделают, увы :(
TEvg-2> Слава Медведу, избавившего нас от тупой и нелепой работы!
TEvg-2> Больше всего бесит именно тупая и нелепая работа.
Вот с этим согласен полностью
TEvg-2> Если там где-то есть гравитация, то приходится с этим считаться как с данностью. Но как можно терпеть, когда какой-то сын собаки придумал дергать часы взад и вперед?
Ну предположим раньше в периоды войн это было оправдано:
Первой страной в Европе, которая использовала идею летнего времени с целью сохранения угля во время войны, стала Германия (с 30 апреля 1916 года) и её союзники в Первой мировой войне. Великобритания, большинство её союзников и множество европейских нейтральных стран вскоре последовали этому примеру, Россия и некоторые страны — в следующем году, а США — в 1918 году[13]. Во многих странах были выпущены однотипные плакаты на данную тему, которые взывали к патриотическим чувствам
 

На сегодняшний день, ИМХО, потеряло свою ценность. Сдается, что человеческие ошибки из-за перевода времени приносят больше урона, чем экономия. Недаром ведь при нормализации ситуации страны оказывались от этой меры.
PS: хотя это все-таки оффтоп в этой теме. Одно дело перевод времени относительного - совсем другое - непонятка с абсолютным.
 49.0.2623.11249.0.2623.112
+
-
edit
 

Balancer

администратор
★★★★★
Monya> Недаром ведь при нормализации ситуации страны оказывались от этой меры.

Ага, так и запишем, что в Великобритании, США, Канаде, почти всех странах Европы (всего — в около 80 странах) ситуация ненормальная :D

Monya> Одно дело перевод времени относительного - совсем другое - непонятка с абсолютным.

Для Жени это проблема одного класса :D
 44
+
-
edit
 

Monya

опытный

Monya>> Недаром ведь при нормализации ситуации страны оказывались от этой меры.
Balancer> Ага, так и запишем, что в Великобритании, США, Канаде, почти всех странах Европы (всего — в около 80 странах) ситуация ненормальная :D
Ну так после ПМВ жеж отказывались. Потом опять пришли к этому
После окончания Первой мировой войны, в 1918 году, Германия отказалась от перевода часов и вновь ввела эту систему в 1940-м под властью Третьего рейха. В 1945 году система была отменена и опять введена в 1949-м в ФРГ и в 1950-м в ГДР. В ФРГ отмена летнего времени произошла в 1960 году, и новое его введение — в период нефтяного кризиса 1973 г.

США отказались от системы летнего времени в 1919 г., снова ввели её в 1941 г., через 40 дней после сражения с японцами на Пёрл-Харборе, отменили после окончания войны, и вновь ввели — в 1974 году
 

Для стран с активно работающей промышленностью это наверное актуально. А вот как для Украины, ИМХО, нафиг не надо.
Monya> Одно дело перевод времени относительного - совсем другое - непонятка с абсолютным.
Balancer> Для Жени это проблема одного класса :D
Это прискорбно. :D
 55.0.2883.8755.0.2883.87

Mishka

модератор
★★★

TEvg-2> Ну вот сдвиг на 1 секунду приносит неприятности, а представь какие неприятности принесет сдвиг времени на час!
Сдвиг времени на 1 час (на 30 минут, на 15 минут — есть и такие зоны) ничего не привносит. Шкала времени не меняется. Жень, нет проблем. Ни для расписания поездов, ни для отчётов, ни для логов по отслеживанию событий. Что в управлении сетями, что в управлении поездами. Вот в первом у меня 10 лет работы, а во втором уже 6. А вот та самая лишняя секунда даёт себя знать по полной. Поскольку на данный момент при вычислениях приходится отслеживать начало и конец интевала, и, если они по разную сторону конца 2016 года, то добавлять секунду.


TEvg-2> А секундными ошибками приходится заниматься полюбасику. Дело в том что часы постоянно уходят, сбиваются, приходится их корректировать. Обычно на 1 секунду.

Женя, установи NTP и всё будет нормально.

TEvg-2> А вот где эта 1-секундная ошибка неприемлима - там городи свою систему абсолютного времени. Всего-то.

Ошибки тут левой улочкой идут. Это отдельная проблема, решение которой известно.

TEvg-2> Ввиду часовых дерганий нам же приходится оперировать абсолютным временем. Вот и сделай суперабсолютное время. А UTC будет относительно него подвирать - это ты уже учтешь програмно.

Нормальные люди всегда используют UTC. Для этого в никсах и есть разные понятия времени — глобавльного и локального. Если это для тебя новость, то, пардон, читать мануалы надо было.
 50.050.0

Monya

опытный

Mishka> Женя, установи NTP и всё будет нормально.
Кстати, нормальные программы диспетчеризации и человеческие SCADA его давно поддерживают - только включить надо :)
 49.0.2623.11249.0.2623.112
+
-
edit
 

HolyBoy

аксакал

Mishka> Нормальные люди всегда используют UTC. Для этого в никсах и есть разные понятия времени…

Более того, даже в, прости господи, виндовсе есть такое.
 45.045.0
RU TEvg-2 #02.01.2017 19:25  @Bredonosec#02.01.2017 02:24
+
-2
-
edit
 
TEvg-2>> В европе и родитель 1 и родитель 2 друг дружку в зад жарят. Мало ли что бывает в европе.
Bredonosec> женя, ты всерьёз не понимаешь разницу между переключением отображения времени при выставленной схеме "timezone UTC +3 winter time", и переводом самого времени?

А ты чё всерьез считаешь, что отбражение времени это такая циферка внизу в трее, используется клерком для оценки времени сваливания с работы и более нигде не используемая? В частности не используемая в АСУ?

Bredonosec> Если какие-то процессы на сервах требуют оценки быстродействия, то перескок на сек назад или повтор секунды будут означать многократное деление на ноль или получение отрицательных величин там, где подобная ошибка не описана, то это будет с немалой долей вероятности означать вылет процесса. Если некие банковские или биржевые программы счиатют рост-падение индексов, то опять же, возможны деления на ноль или отрицательные значения там, где подобное никто не описывал.
Bredonosec> И т.д. и т.п.

Подобные оценки и расчеты требующие субсекундной точности не делаются по часам писюка, ввиду грубости последних. Часы на писюке тикают 15 раз в секунду и достоверно показывают только секунды. Что качается милисекунд - это не реальные миллисекунды, а цена на дрова.

Отматывание 1 секунды технически ничем не отличается от подобной же операции при синхронизации часов. Часы в компах глючные, постоянно врут. Приходится их подводить, синхронизировать с первичными часами. А если у тебя в проге при этом произошло деление на ноль, значит ты дятел. Учись писать правильно.
Ошибка расчетов возникающая при подводе часов небольшая и отрабатывается легко.
Важно что погрешность в 1 секунду обычно не является человечески значимой. Для человека секундой больше или меньше - незначительно и неощутимо. И изменения в работе на 1 сек совершенно не меняет ритм работы, не меняет техпроцесс и как правило проходит мимо сознания человека.
Как правило и в технических процессах 1 секунда не имеет большого значения в рамках длительной работы. Для быстротечных процессов 1 секунда может иметь значение. Однако как правило обычно не важно (в рамках секундной ошибки) где именно расположился сей процесс на шкале глобального времени. Т.е. сам процесс может контролироваться быстродействущим таймером, относительно момента Т0. А вот погрешность самого момента Т0 относительно UTC может быть в рамках 1 сек и в 99,99% случаев от этого никто не охнет.

Bredonosec> И искать, в какой из миллионов программ что может переглючить с непредсказуемыми последствиями - такой геморрой, что пресловутая иголка в стоге сена - просто образец простоты.

А что может проглючить в при переводе часов на 1 час, вам не интересно?
Вот у нас стояли интеллектуальные счетчики евроальфа. В них была своя память и с них можно было получить кучу параметров, включая например реактивную мощность и искажения фаз.
Очень удобная штука, не раз выручала. Например накрылся сервак. Поднял сервак, поднял оракл и последний дамп из бэкапа. Счетчики опросились и информация с них стянулась. И в итоге нет дырки в данных. Красота.

Но в счетчиках были свои часы. И эти часы имели свойство переводиться. После чего с счетчика лезла не корректная история, а какая-то херня. А может быть в счетчике внутри все хорошо, а глючила софтина которая его обслуживала. Сложная система набирается из компонентов, которые делали разные фирмы и разные люди. Поскольку они между собой никак не договаривались, то подобная хрень время от времени вылезает.

Считалось электричество (система сделана на Украине), считался уголь (система была сделана москалями), а потом считался удельный расход причем в рамках не UTC, а местного времени.
За хороший удельный расход смену поощряли. За плохой лишали премии. А за криво посчитанный этот параметр, материально пострадавшие коллеги могли и морду побить.
А вот 1 секунда погоды не делала. За 1 секунду станция могла сожрать 70 килограмм угля, а допускалась погрешность 1,5%.
 33.033.0
1 2 3 4 5

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru