subsecond timestamp support

[cheebusjeebus]

my files has nanosecond precision on his mtimes (and a/c/btimes) that i want retained in ZPAQ archive (and i also want for archival date)

currently zpaqfranz (and zpaq 715) only support seconds but he does NOT support for subsecond precison (nanoseconds preferred like unix/linux)

((you see windows timestamp granularity utiliseing stat of msys))

kindly adding of option like -nsfiletimes and -nsarchivetimes (all in simple -nsalltimes) for add and list? thanks you sir

---

example list >> 0001 use -nsfiletimes, then 0002 use -nsalltimes or -nsfiletimes -nsarchivetimes:

E:\>zpaqfranzhw l "E:\artwork.zpaq" -all -nsalltimes 
zpaqfranz v63.2d-JIT,SFTP-L,HW BLK3,SHA1,4,SFX64 55.1,(2025-08-23)

<<E:/artwork.zpaq>>: 2 versions, 2 files, 65.541.010 bytes (62.50 MB)


   Date           Time           Size Ratio  Ver Name/Info
---------- ------------------  ------------ ----- ---- ----------
2025-09-06 20:16:27.000000000 [  60.264.889   Ver 0001| Files: changed/added 1 removed 0
2022-11-16 13:25:27.488649600    64.806.503   95% 0001|+ tree palm.psd
2025-09-06 20:17:34.327764061 [   5.276.121   Ver 0002| Files: changed/added 1 removed 0
2022-11-17 01:27:11.198590775    74.513.548   89% 0002|# tree palm.psd

          139.320.051 (132.87 MB) of 139.320.051 (132.87 MB) in 4 files shown
           65.541.010 compressed  Ratio 0.470 <<E:/artwork.zpaq>>
0.016s (00:00:00,24.73KB) (all OK)

E:\>

an option to show nanosecond for 0.016s (00:00:00,24.73KB) (all OK) and all ETA would helpful but he is not as necessary as file times and archive times

[fcorbelli]

It is a choice due to the mechanism used to determine which files to add, or rather update, in the case where -force is not used.

Filesystems are not always reliable and, therefore, not using a tolerance can easily cause a catastrophic slowdown in the update.

In a perfect world, every filesystem would report date information flawlessly, but this does not happen for a variety of reasons (it also depends on the filesystem itself).

[cheebusjeebus]

thanks you fast respond, however i am unsure what you saying

on linux/unix:

$ stat informations.txt
  File: informations.txt
  Size: 1086            Blocks: 8          IO Block: 4096   regular file
Device: 8,2     Inode: 102298687   Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-08-12 22:06:09.381676983 +0000
Modify: 2025-07-13 08:56:14.123218815 +0000
Change: 2025-07-13 08:56:14.123218815 +0000
 Birth: 2025-05-03 17:42:15.850468373 +0000

on linux with GNU ls:

$ ls --full-time informations.txt
-rw-r--r-- 1 root root 1086 2025-07-13 08:56:14.123218815 +0000 informations.txt

on windows with GNU stat of msys64 (i copied file here from linux host):

C:\>stat informations.txt
  File: informations.txt
  Size: 1086            Blocks: 4          IO Block: 65536  regular file
Device: 840a0ec5h/2221539147d   Inode: 5629499534248474  Links: 1
Access: (0644/-rw-r--r--)  Uid: (191604/   Usern)   Gid: (191302/    None)
Access: 2025-09-07 17:03:19.226458700 +0000
Modify: 2025-07-13 08:56:14.123218800 +0000
Change: 2025-09-07 17:08:36.718963200 +0000
 Birth: 2025-09-07 17:03:18.886743400 +0000

my question is if these subseconds stored and recognized by both OS can be optionally used in archives (at least to file times). thanks you sir

[fcorbelli]

The problem, when considering file timestamps with too much precision (without rounding or tolerance), is that files may have been copied or moved around.

Suppose you have the file pippo.txt in the /dati folder, with a certain timestamp, and you add it to a zpaq archive. Now copy pippo.txt into the /spostato folder.

At this point the question is: will the timestamp be exactly the same?
The answer is: we cannot know for sure. This is because /spostato could be a different filesystem (for example another disk or mountpoint) that uses a different level of timestamp precision.

Remember: for the computer there is no such thing as “almost equal.”
Either two values match exactly, or—even with a minimal difference, say a microsecond—they are considered different.

The result is that zpaq will interpret the file pippo.txt in /spostato as “modified” and will read it again, even if it is actually the same file.

This is why zpaq introduces a tolerance on timestamps (larger on Windows than on Linux): it serves to absorb these micro-differences and avoid unnecessary reads.

Incidentally, this is completely normal on Windows, where the FAT filesystem can even have a timestamp granularity of two seconds (!)

So what exactly is the function you need?

Is it really important for you to know the exact millisecond when a file was modified, or is a single-second precision enough?

The matter is even more complicated because the computer’s clock does not necessarily match the filesystem’s clock. That is, the function that returns the current ticks generally works in milliseconds, while the filesystem “on its own” may have a different resolution. In short, working on different operating systems with different filesystems requires maintaining a kind of “tolerance” to make these distinct worlds interoperable.

[cheebusjeebus]

thank you for explaination. i understand changes in timestamps when copying between filesystems, where it may alter subseconds--this happen to me on my test, last 2 digit change to 00 (see mtime particularly).

for me this is helpful to retain accurate file timestamps, and i keep one ZPAQ per filesystem contents, so no cross-filesystem file copies are common (i have script on POSIX system and he checks mtime and restore if needed--for windows there is no help, see above, i think he is NTFS limitation or windows API limitation)

i have relyed on subseconds where i see which files in dirtree is modified myself. for example, dirtree of videogame datas all use whole seconds, but with find and stat i can quickly see files modified myself with help of which utilise subseconds--with this lost there becomes confusion for my situation

if this will never be added to zpaqfranz, is understanding, because i can still utilise tar who retain these subseconds and zpaqfranz on my tar

[fcorbelli]

Short version: zpaq encode the date inside a int64_t, with only seconds.
Changing is very hard

Sorry

[cheebusjeebus]

thank you for considering and researching, please don't feel sad. please can i leave issue ticket open for small chance of future change? i am no expectation of ever subseconds support added--he is a dream for distant future.

[fcorbelli]

Of course I can make this happen (subsecond-time)
But this really needs a whole lot of work
Maybe in the future

[cheebusjeebus]

thank you sir, i wait with high patience :)