Skip to content

pmirror and pdist should use better time precision #168

Open
donald opened this issue Apr 13, 2021 · 1 comment
Open

pmirror and pdist should use better time precision #168

donald opened this issue Apr 13, 2021 · 1 comment

Comments

@donald
Copy link
Collaborator

donald commented Apr 13, 2021

Currently we use perls native lstat(), which returns the time values as integer seconds as in the old days (time_t type)

For modification we use perls native utime() which also uses integer seconds.

We already use utimensat(), which is the system call to use struct timespec type but only for the purpose of setting times for symbolic links with AT_SYMLINK_NOFOLLOW and with the nanoseconds set to 0.

Maybe we can use lstatand utime of Time::HiRes. I'm not sure if this give the full struct timespec nanoseconds resolution, though. It converts the time values to perl scalar number values. In theory, these could have any resolution (when stored internally as a string) but Time::HiRes might use other types internally.

If we change something here we should bear in mind that existing copies of files might look different from the original files because of the former truncation of time values.

@donald
Copy link
Collaborator Author

donald commented Apr 13, 2021

Internally, Time::HiRes uses double 1 ( NV is double "number value"), this is 53 bit precision.

Today we need 31 bit for the seconds part and 30 bit for the nanosecond part, so that is more and we loose precision when this is converted to float and back. This can be demonstrated:

buczek@theinternet:~/x$ stat -c "%x" /scratch/local/x.dat 
2021-04-13 09:02:33.251170618 +0200
buczek@theinternet:~/x$ perl -MTime::HiRes -e 'printf "%30.20f\n",[Time::HiRes::stat("/scratch/local/x.dat")]->[9]'
1618297353.25117063522338867188

As expected, the number is not exact to the nine decimal places we need for nanoseconds. So with Time::HiRes we'd have sub-second precision but still not the exact match to file system precision.

Sign in to join this conversation on GitHub.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant