From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.ada
Subject: Re: GNAT Modification_Time limitation
Date: Mon, 19 Nov 2018 17:33:04 -0800
Organization: None to speak of
Message-ID: <lnefbgr0rz.fsf@kst-u.example.com>
References: <0577e947-d691-4b81-aca6-b2e86bbef634@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader01.eternal-september.org;
 posting-host="8289db2fe6d41663062a728578d5f4f5";
	logging-data="23483"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1892w+EEQu9/N0m/Et9qMyN"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:t8mHK/iJc5jcl9YzexYKg7qKD/4=
	sha1:CdJ97zHiFkVb/e72ZJO/FZtlsQ0=
Xref: reader01.eternal-september.org comp.lang.ada:54845
Date: 2018-11-19T17:33:04-08:00
List-Id: <comp.lang.ada>

Lionel Draghi <lionel.draghi@gmail.com> writes:
> I am coding a kind of make application, that depends on file's time
> tag (thanks to Ada.Directories.Modification_Time), and on
> Ada.Calendar.Clock, both returning Ada.Calendar.Time.
>
> Unfortunately, I came across a GNAT limitation in the
> Modification_Time implementation on Linux : sub-second are ignored,
> and Modification_Time returns
>> Time_Of (Year, Month, Day, Hour, Minute, Second, 0.0);
>
> So, at the same time Clock returns 2018-10-29 20:36:01.47
> while Modification_Time    returns 2018-10-29 20:36:01.00
>
> This prevents me from knowing if a file is modified before or after
> certain time, and thus undermine my efforts.
>
> My workaround was to impair also Clock precision, with an ugly rounding:
>> Time := Ada.Calendar.Clock;
>> New_Time := Time_Of
>>   (Year    => Year (Time),
>>    Month   => Month (Time),
>>    Day     => Day (Time),
>>    Seconds => Day_Duration (Float'Floor (Float (Seconds (Time)))));
>
> But that's not a correct solution either : I have to order lots of
> file creation, and having all files created during the same second
> returning the same time tag also prevent my algorithm from properly
> working.
>
> Any workaround to get a precise file time tag? 
> Or to compare file's time tag with Clock?

It's odd that GNAT's Modification_Time truncates the time to
one-second precision.  A quick experiment on my system (Ubuntu 18.04)
also indicates that it does so, even though the system stores the
timestamp in nanosecond precision.

On Linux 2.6 and later, the underlying stat() system call gives you
a "struct timespec" value for the modification time, as specified
by the current POSIX standard.  (struct timespec represents times
with nanosecond precision.)  A file system isn't required to store
times with that precision, but many do.

If you're on a POSIX system, you should be able to call the stat()
system call and *probably* get a more precise timestamp.

If you're on a non-POSIX system, there might still be a
system-specific way to get a more precise timestamp.  (NTFS also
seems to store timestamps with high precision.)

(And remember that nanosecond precision doesn't necessarily imply
nanosecond accuracy.)

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"