What is the purpose of this change?

First of all, thank you so much for this amazing project! 🙂 I found Rclone extremely useful and very well done.

In this very simple PR I'm adding support for two new time formats: unix and unixnano. The reason behind this is that sometimes I use the rclone lsf command like this:

$ rclone lsf -R --format=pst --time-format=RFC3339 myremote:/
myfiles/;-1;2025-08-04T13:00:00+02:00
myfiles/file01.txt;123;2025-08-04T13:10:00+02:00
myfiles/file02.txt;456;2025-08-04T13:20:00+02:00
myfiles/file03.txt;789;2025-08-04T13:30:00+02:00

to generate a sort of CSV-based "tree" of a directory (either local or remote) with file sizes and last modification times. But the output of such command is timezone-dependent (note the +02:00s). So, if I run the same command on one of my servers, which has a copy of the same folder but the system time zone set to UTC, I get this:

$ rclone lsf -R --format=pst --time-format=RFC3339 myremote:/
myfiles/;-1;2025-08-04T11:00:00Z
myfiles/file01.txt;123;2025-08-04T11:10:00Z
myfiles/file02.txt;456;2025-08-04T11:20:00Z
myfiles/file03.txt;789;2025-08-04T11:30:00Z

So, even if the content of the directory is exactly the same, I'm unable to programmatically compare the two outputs, e.g. using the diff command.

Since Unix timestamps are timezone-agnostic, with this PR I'm introducing the possibility to do this:

$ rclone lsf -R --format=pst --time-format=unix myremote:/
myfiles/;-1;1754305200
myfiles/file01.txt;123;1754305800
myfiles/file02.txt;456;1754306400
myfiles/file03.txt;789;1754307000

And:

$ rclone lsf -R --format=pst --time-format=unixnano myremote:/
myfiles/;-1;1754305200123456789
myfiles/file01.txt;123;1754305800123456789
myfiles/file02.txt;456;1754306400123456789
myfiles/file03.txt;789;1754307000123456789

I hope this is useful :) let me know what you think. Thanks in advance!

Was the change discussed in an issue or in the forum before?

I don't think so. I tried to search but couldn't find anything related :)

Checklist

• I have read the contribution guidelines.
• I have added tests for all changes in this PR if appropriate.
• I have added documentation for the changes if appropriate.
• All commit messages are in house style.
• I'm done, this Pull Request is ready for review :-)