Собственно, согласен, просто заметил несоответствие и года, и часа, и минут. Пробую сейчас сравнивать Юникс время. Проблема осталась в сохранении переменной и чтобы она не успевала перезаписываться при включении.
Вид для печати
А моих макросах http://www.owen.ru/forum/showthread....l=1#post219996 ошибок нет
Вложение 30264
Вложение 30265
Вложение 30266
Там же http://www.owen.ru/forum/showthread....l=1#post219991
Цитата:
ВНИМАНИЕ.
Т.к. в ПР не поддерживается работа со знаковыми целыми числами, макрос будет корректно работать только с даты "эры Unix" - с 0 часов 1 января 1970г. Зато не будет проблемы 2038г, когда 19 января 2038 многие системы сойдут сума и время у них потечет вспять. У нас, в макросе, эра Unix закончится 5 февраля 2106г.
petera с какого перепуга ? кто-то сам утверждал, что для процессора ПР200 числа меньше 0 он воспринимает как должное отрицательное число.
эра Юних может считать от 0 часов 1970 года в оба направления и в целом там проблемы нет. Вопрос как будет считать макрос ? может он выдать время 1902 год или КУ?! ?
Проблема может возникнуть, если человек в программе привяжется ко времени.
Мой макрос может считать только с с 0 часов 1 января 1970г, время 1902 год он не выдаст.
Зато он правильно работает до 5 февраля 2106г.
ЗЫ
Я утверждал, что преобразование TO_INT работает по всем правилам - преобразует отрицательное вещественное число в целое со знаком в дополнительном коде.Цитата:
кто-то сам утверждал, что для процессора ПР200 числа меньше 0 он воспринимает как должное отрицательное число
А любые арифметические операции с числами в дополнительном коде выполняются верно в любой комбинации - друг с другом и с целыми положительными числами
Вложение 30276
Понятно, будет проблема при передаче времени в ПК например, мы ему 19 января 2038 года, а ПК нам расскажет, что сейчас 1901 (или какой там в Юникс времени) год :)