Dilma, если в секундах от РХ, то хватает 4-х байтного integer, а если в мсек или мксек, то это уже int64

В Real тоже самое. Просто потерь от системного времени компа в мс нет пока...
Собственно разница-то во множителе 86400 и адитивной константе (количество дней от РХ до 1970г - не считал).
Просто это все уже есть.

Ну хорошо: есть три формата: text, integer, real
Конвертор на 6 направлений (любой в любой)
И св-во маска - с вышецитированными KOL-овскими ключами...


Дык мне кажется что и с прямым не очень-то получится... Без маски-то.

не тоже самое. Если в KOL формат времени типа real это дата-точка-время, то получение следующего интервала это
next_time = cur_time + (h*60*60)/real_const
даже если не брать это во внимание, то мне как рядовому пользователю понятно, что такое "число секунд" и что с ними делать, а вот что такое real мне не понятно совершенно.

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

Абсолютно все понятно - временной интервал в днях.
Расстояния меряют в километрах, ярдах, и т.п.
Ну и время так же: в секундах, в сутках, и т.п.

Точно так же все: прибавишь 1/24-ю суток - значит добавил час.

Говорил про то, что если выводить данные из базовых элементов, то обязательно без потерь
Системное время - int64
Real - еще без потерь, а integer - уже потери (доли секунды).
Если можно терять эти доли, то это должен быть выбор пользователя, а не наш.
Он и выберет Time-конвертор в режиме Real -> Integer. Имеет право.
Но предписывать ему это - уже мы не имем право.
Быть умнее пользователя - это не русский стиль, это буржуйский, ИМХО

А вот где бы про этот KOL прочитать, т.е. справку по нему? И если не тяжело объяснить на примере этой процедуры Что означает каждое так сказать слово: где служебные слова hiasm, где стандартные pascal, а где KOL
Вопрос - получаемый код hiasm'a это delphi(простите мое невежество это всетаки язык или среда разработки?) или object pascal?

1) http://kolmck.net/docs/KOLBook.rar
Но, по словам Кладова - лучшая справка, это KOL.pas

2)

3) Среда. И компилятор без IDE (dcc32) тоже надо полагать - Delphi. Коды HiAsm и на FPC работают. По большому счету. Который расшифровывается как Free Pascal Compiler

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

GRIMAN, - работает; обратите внимание на разделители даты: должны быть точки

[size=-2]------ Добавлено в 10:39
А под FPC не работает, почему бы это?

Знаю я одно место, где в днях любят, но не от Р.Х., а от 30.12.1899, причём конкретно этот день считается просто временем без даты, т.е. интервал 0 ... 1.0 это время без даты, его удобно складывать с самой датой без времени. Соответственно 01.01.1900 = 2.0


Чем не нравится формула next_time = cur_time + h/24.0?


Без указания маски используется маска, установленная в системных настройках.

Galkov, честное слово смахивает на издевательство Я о чем говорю? О возможно разобраться в формате? О том, что в чем измеряется? Я начал с того, что предложил выбрать наиболее простой, понятный и удобочитаемый формат без дополнительных конвертаций

По-вашему получается, что запись 0,0416( 1/24 то бишь один час в системе real) это гораздо более удобное и самое главное Абсолютно понятное представление времени, нежели 3600...


Я предпологал, что речь в топике идет о времени, представимом для пользователя. Это значит, что мы говори м о:
- датах создания, модификации и прочего для файлов
- системное время
- время возникновения тех или иных событий
- длительность медиа файлов
- и прочее в таком же духе

Все эти времена должны измеряться с точностью до долей секунд
А есть уверенность, что ОС Windows вернет скажем время создания файла с такой точностью

Может я просто не понял постановки задачи... Но еще раз повторюсь - лично я могу привести примеры(и не один), когда представление в виде целого числа удобно и прозрачно. Можно ли привести примеры для real?

Уточню: я НЕ ИМЕЮ ПРАВА решать с какой точностью захочет их измерять наш пользователь - программист на HiAsm

Вот решили мы (хотя не совсем мы, конечно), что размер файла - это integer. И хоть я и считаю, что файлы в 10Гиг - это бред сивой кобылы, но это решение все равно не правильное.
И именно по вышеуказанной причине.


Наиболее простой и удобочитаемый формат, это текстовая запись числовых констант по выбору пользователя.
Например:
2*60+53 - это более понятно чем 173 секунды
3+2/24 - это более понятно чем 3.083 суток
Да и hex-записи в других случаях могут понятней оказаться.
И я сторонник такой понятности.
Чем это отличается от предыдущего: в такой понятности нет потерь.
Если они будут - и я буду сразу против.

Вот сегодня CodeGen не предоставляет пользователю использовать такую строку как константу: "ABCXYZ"
А среда - запросто
Так это не правильно. И обсуждать: "а может такого и не нужно..." - бессмысленно.
Ровно по той же самой причине - не наше это дело.
Просто сделаю.
По-позже как-нибудь.

[size=-2]------ Добавлено в 22:20
Dilma, зачем обратные косые "съедаешь"

вопрос остался без ответа:




файлы большие 4гб это не бред - образ двустороннего DVD диска. Однако мы не о точных велечинах говорим, а о принятие некоторого формата. А именно секунды и доли секунды. Почему секунды? Я сказал уже несколько раз. Почему доли секунды? Нормального ответа не увидел, кроме проблемы потери точности. Однако опять таки же не увидел аргументов в пользу долей секунд против скажем миллионных долей секунд. Проц между прочим легко позволяет такие интервалы мерить.


не вижу, к чему и зачем этот пример приведен. Я с ним полностью согласен. Однако мы сравниваем запись времени в виде числа секунд(integer) и долей секунд(real), а не их возможные представления.

К стате Галков на моём диске сейчас самый большой файл это 28 ГБ. Но и это даже, при моей работе, считаеться маленьким файлом.