Petermint wrote:Does this mean it will add 11 hours to the date/time every time I copy a file from an external source?
No. The behaviour is as explained limited to files copied from a FAT filesystem. Well... probably there are other filesystem types that care about the timezone but certainly FAT is the only one you are likely to encounter. Again, what is happening is the following.
The systemd initialization system, in Mint new to version 18, since its own version 216 does not inform the kernel of the timezone of the system if the hardware clock is kept in local time rather than UTC. This so as to avoid unsolvable issues with time going back, especially or specifically (not sure) when daylight savings time is thrown into the mix. This makes technical sense in and of itself, but what it ends up meaning is that the FAT FS-driver inside the kernel continues labouring under the assumption that it should not be applying a timezone offset to reported timestamps; that, in that sense, the on-disk timestamps are in UTC, even though they are in fact in local time [edit: edited out a brain-inversion here].
As to the solution, a good one would be to tell your camera to save the files with UTC timestamps if this is possible. I have no experience with digital camera's but shall assume it is not -- and/or that Windows makes no provisions for UTC timestamps on FAT whereby you would then conversely see wrong timestamps in Windows.
The best and at the very least most practical solution is to set your hardware clock to UTC as per earlier reply. This avoids the mentioned systemd issue and should leave you without trouble going forward. If you are dual booting with Windows, this does mean you need to tell Windows that
your hardware clock is in UTC on that machine. Depending on which version of Windows, this is either easy or troublesome. Google it.
Repairing earlier copied files is not hard. For a single file you would do something like
Code: Select all
touch -d "$(date -Rr foo.jpg) - 11 hours" foo.jpg
which you can script around for entire directories or trees.
LM is now the same as Windows. You have to very carefully test everything after every upgrade then waste time switching off the stupid stuff.
You would have found the exact same behaviour on any distribution using systemd, which by now means any relevant one. Yes, systemd has a very worrying tendency and history of distributing its problems to everyone else -- but seeing as how anyone who in fact investigates time issues quickly agrees that keeping system time not in UTC is a very bad idea to begin with, this particular instance of it is not one many care deeply about. Use UTC and you will have no trouble.