p_govorun: Час сурка

vap@lj
2005-10-29 13:22 (ссылка)

На эту же тему: IBM PC Real Time Clock should run in UT (http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html)

Туда же: банковские правила вычисления сложных процентов - весьма часто в договоре прописаны такие правила, при которых функция проценты (время) - разрывна и, вообще говоря, даже иногда не монотонна!
Туда же - прогрессивные налоги, функция налог (налогооблагаемая база) которых - тоже не только разрывна, но и не монотонна.

Ну а необдуманная привычка немалой части человечества пользоваться кредитными картами - вообще песня с точки зрения специалиста по информационной безопасности :)

(Ответить) (Ветвь дискуссии)

p_govorun@lj
2005-10-29 13:42 (ссылка)

Да, перводить часы в bios -- дело дурацкое.

Есть ещё интересная тема -- как именно MS Windows ставит время доступа к файлам на FAT. Я с этим не разбирался, но подозреваю, что там тоже всё запутано.

Про немонотонные налоги я слышал такую историю: какая-то голливудская кинозвезда снялась в фильме за гонорар в миллион долларов (по тем временам сумма экстраординарная даже для Голливуда). Ей предлагали, чтобы уменьшить налог, взять гонорар в $999999 (при этом на руки она получила бы больше), но она потребовала полноценный миллион, не считаясь с потерями.

(Ответить) (Уровень выше)

	dottedmag@lj 2005-10-29 13:41 (ссылка)
	Нормально всё будет. Это только недооперационки хранят время в локальной таймзоне. А все прогрессивные (tm) - в UTC, и только при показывании пользвателю в локальную таймзону переводят. (Ответить) (Ветвь дискуссии)

p_govorun@lj
2005-10-29 13:48 (ссылка)

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

dottedmag@lj
2005-10-29 13:51 (ссылка)

Нет, не нужно. У меня сейчас выставлена таймзона NOVST, в которой записано: "при UTC от такого до такого времени локальное - это +7, а при UTC от такого до такого - это +6", и всё. Это влияет только на отображение дат.

(Ответить) (Уровень выше) (Ветвь дискуссии)

p_govorun@lj
2005-10-29 13:59 (ссылка)

Я знаю. Время в unix считается в секундах от 1 января 1970 года UTC и его никто никогда никуда не переводит. И это правильно.

Беда с идеей перевода времени именно в том, что взялись переводить "самые первичные" часы (и именно в этом и состояла задумка авторов идеи). Тут-то проблемы и начались...

(Ответить) (Уровень выше) (Ветвь дискуссии)

	dottedmag@lj 2005-10-29 14:02 (ссылка)
	Так. А где у нас переводят первичные часы? (Ответить) (Уровень выше) (Ветвь дискуссии)

	p_govorun@lj 2005-10-29 14:11 (ссылка)
	Кремлёвские куранты :-) Я надеюсь, что до атомных часов идея перевода времени не добралась. (Ответить) (Уровень выше)

andrzejn@lj
2005-10-29 14:01 (ссылка)

А что будет, когда люди расселятся по нескольким звёздным системам, с планетами, астероидами, космическими станциями и кораблями на субсветовых скоростях...Take the Traders' method of timekeeping. The frame corrections were incredibly complex, and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth's moon. But if you looked at it still more closely... the starting instant was actually some hundred million seconds later, the 0-second of one of Humankind's first computer operating systems.

V.Vinge. "A Deepness in the Sky"

(Ответить) (Ветвь дискуссии)

	dottedmag@lj 2005-10-29 14:02 (ссылка)
	Да! Я это тоже отметил, когда читал ;) (Ответить) (Уровень выше)

p_govorun@lj
2005-10-29 14:08 (ссылка)

При cубсветовых скоростях понятие "Гринвичское время" обретёт новый смысл: это будет время для того, кто физически находится в Гринвиче. При перемещении в пространстве нужно будет делать поправку на скорость движения.

Vinge я не читал. Но подозреваю, что он имеет в виду именно unix epoch, 01.01.1970. Если этот отсчёт времени переживёт без изменений 2038 год, он, скорее всего, останется очень надолго.

(Ответить) (Уровень выше)

gray_bird@lj
2005-10-29 16:14 (ссылка)

С переводом часов есть один веселый прикол.
Есть такая смешная программа 1с бухгалтерия, в ней проводки формируются на основании документов. Так вот документики, кроме даты операции, что логично, имеют скрытый атрибут время создания. Причем, если расходная накладная на секунду раньше приходной, фиг чего со склада отгрузится. Радостно будет сообщено, что "ничего нет". Предполагаю, что и масса других программ используют сходный механизм расставления документов в пределах одного дня.
Представим себе к примеру круглосуточный ресторан. Администратор в 02-30 сделал перемещение со склада продуктов на кухню, через полчасика пришел клиент и заказал еду, пока офицант дошел, наступило 03-10, но в 03-00 система перевела время на час и стало опять 02-00, при попытке списать продукты система скажет, а нефига нет. готовить не ис чего. Еще веселей, если закрытие чека произойдет РАНЬШЕ чем открытие.

Кстати, забавно что,
Время переводят в одно и тоже локальное время в разных часовых поясах, получается, ночью на один час время в соседних часовых поясах СОВПАДАЕТ.

(Ответить) (Ветвь дискуссии)

p_govorun@lj
2005-10-29 16:29 (ссылка)

И опять: да здравствует unix time! Если бы 1С использовала его, всё было бы в порядке.

Впрочем, у официанта есть вариант: принести клиенту еду через час с небольшим, показать часы, по которым прошло несколько минут, и объяснить, что ресторан следует государственной политике перевода времени :-)

(Ответить) (Уровень выше)

birdwatcher@lj
2005-10-29 21:08 (ссылка)

У меня был ежедневный крон джоб в два часа пятнадцать минут ночи. И весной в один прекрасный день он не отработал, потому что в тот день это время не наступило. Причем я сам не сообразил, почему.

(Ответить) (Ветвь дискуссии)

p_govorun@lj
2005-10-30 09:24 (ссылка)

Да, ещё одна напасть.

Кстати, я только сейчас сообразил, что crond -- единственная часть unix, использующая местное время, а не юниксовое. Все остальные программы используют местное время только для общения с пользователем.

(Ответить) (Уровень выше) (Ветвь дискуссии)

dottedmag@lj
2005-10-30 09:33 (ссылка)

Кстати, из мана Vixie Cron: "Special considerations exist when the clock is changed by less than 3 hours, for example at the beginning and end of daylight savings time. If the time has moved forwards, those jobs which would have run in the time that was skipped will be run soon after the change. Conversely, if the time has moved backwards by less than 3 hours, those jobs that fall into the repeated time will not be re-run."

Так что здесь уже всё починили.

(Ответить) (Уровень выше) (Ветвь дискуссии)

	p_govorun@lj 2005-10-30 09:58 (ссылка)
	Разумно сделано. Но всё равно проблемы могут найтись. Например, нет способа запускать нечто каждые два часа, независимо от перевода времени. (Ответить) (Уровень выше)