Linux Mint shows wrong time for photographs [SOLVED]

[Petermint]

Using the same camera and Linux Mint for years. No problem with photograph dates or times. After upgrade to Linux Mint 18, the time on photographs are wring. It looks like LM 18 is assuming the times are UTC then adding 11 hours for the time zone.

How do I tell LM 18 to stop being stupid and go back to the right way?

Is there a way to find out if LM18 is just changing the date/time for the display or if the date/time is permanently damaged on import?

Is there a file manager, or setting, to show the real date/time?

You can set LM 18 back to use the real time using:

Code: Select all

timedatectl set-local-rtc 1

[Petermint]

I double checked old imports. Files copied from my SD card from 2010 to 2015 are displayed with the correct date/time.

There are no changes to the camera software.

[BenTrabetere]

It looks like LM 18 is assuming the times are UTC then adding 11 hours for the time zone.

The first thing I would do is check the Time/Date settings on your camera. An 11 hour error sounds like a Daylight Savings Time shift gone haywire - more than once I have incorrectly set the time on one of my cameras ... 1pm is 13:00:00, not 01:00:00. Also +/-11 hours UTC is mostly the watery part of the Pacific Ocean.

The next thing I would do is take a few pictures - review the images in the camera, making note of the time stamp. Next, place the SD card in a reader and view the images from the card; the time stamp should be the same as it was in the camera. Finally, import the images and check the time stamp.

You can modify or edit the EXIF time stamp. I would advise against it - messing with EXIF can damage files, and sometimes the damage is not immediately noticeable. Before you edit the EXIF you should create a backup for any image you do not want to lose.

[rene]

How do I tell LM 18 to stop being stupid and go back to the right way?

Setting your hardware clock to UTC should work. That is: timestamps on FAT are a known issue in systemd, introduced/changed in systemd 216, where it refuses to synchronise time back to the kernel when the RTC is kept in localtime so as to avoid "time going back" pitfalls. If you have no pressing need for RTC in localtime setting it to UTC will be the best fix:

Code: Select all

timedatectl set-local-rtc 0

According to the timedatectl man page, this will not only tell the system that the RTC is kept in UTC but also in fact set it such. I'm not running 18 so make sure of that.

If you have a pressing need for RTC in localtime, a dual-boot with an old Windows version perhaps, then things get clumsy. The "tz=UTC" or "time_offset=<minutes>" mount options for the (V)FAT filesystem help but are straight-forward to specify only when you mount manually. When auto-mounting I am not in fact sure where in Mint you'd specify a mount option; might need to be through udev. Shall not attempt to find out unless you specify that keeping the hardware clock in UTC is really not an option.

[Petermint]

@Ben, Thank you for you suggestions. I have already used those tests. The results today are the same as last week.

Time/Date settings on your camera

The date/time settings are correct and have not changed from 2010.

watery part of the Pacific Ocean

I live on the coast.

The next thing I would do is take a few pictures

I made hundreds today. The images from today are exactly the same as the ones from before my post. They have the correct date/time in the camera and on one of the other computers here, a computer not converted to LM18.

When I list the images from the card in LM18, the list shows the wrong time. Both Nemo and ls show the wrong time.

Before you edit the EXIF you should create a backup for any image you do not want to lose.

I never edit an original.

@rene

Setting your hardware clock to UTC should work.

What happens to the files already on the computer?

I will backup my whole disk before testing. There are close to a terabyte of images on my little notebook. Most of them have the correct date/time.

[Petermint]

I found and read viewtopic.php?t=223479.

If the system is storing date/times as local time, why is it suddenly changing the date/time on new files but not old files? If it is not changing the date/time on old files, how can the old files display the correct date/time?

Why was there no warning that LM18 is going to change date/times without permission?

[Petermint]

The pre LM18 files in the ext4 partition have the right time. Somewhere near 20,000 new images are damaged. LM18 must damage the time during import to the Ext4 partition. Does this mean it will add 11 hours to the date/time every time I copy a file from an external source?

Changing the computer to UTC might stop more damage but will still leave the new files with the wrong data/times.

If the damage is limited to files from FAT, how can I remove that behaviour?

As a temporary measure, I will use a Windows 7 computer to save the original files to an NTFS disk and never let Linux touch the originals.

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.

[rene]

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.

[Petermint]

Thank you to everyone who mentioned NTFS. For my current copy, I booted Windows, copied from the SD card to an NTFS disk then copied from NTFS in LM18. The date/times are correct.

The conversion will have to wait due to a big project not requiring pictures. When that is over, I will backup and change the date setting.

Cleaning up will be fun. For most photographs, the time does not matter, only the date. Any photograph taken in the afternoon will have the wrong date.

Thank you for your help. I will mark this as solved.

[Petermint]

Not solved. The copy via Windows and NTFS worked once. Now it is broken. Windows copies from FAT to NTFS with the correct date/time. Linux copies from NTFS with the same error as the copy from FAT. The Linux NTFS code is making the same mistake as the Linux FAT code.

[rene]

That really makes very little sense. The FAT issue is well-known but NTFS on-disk timestamps are in UTC both in Windows and Linux. It's only when displaying them that either OS converts them to local time. If there's a difference between what Windows and Linux display it can only be the case that Windows and Linux now have different ideas of what the offset between UTC and localtime is, what the timezone is, something which you may have introduced while experimenting. It is very easy to confuse oneself regarding displayed versus on-disk timestamps (and plus versus minus; just edited one of those out of an above reply) but as long as Linux copies from an NTFS filesystem and from nor to a FAT filesystem not any supposed Linux mistake is involved here: Windows copied the files to NTFS from FAT and at that point converted timestamps from localtime to UTC. After that nothing touched on-disk timestamps; Linux could only be involved, and only in the display-sense, if it now has a wrong timezone setting.

In any case: it is still the case that simply switching the Linux system over to keeping the hardware clock in UTC as per above should solve things for you going forward. You have not specified whether or not the Linux system is dual booting Windows, and if so with what version of Windows. If it's a dedicated Linux machine just switch its RTC to UTC via the above timedatectl command. Nothing happens to current on-disk timestamps for existing files, not even those on obsolete filesystem types such as FAT.

[Petermint]

I am looking at settings. will log them in this post. The LM18 Date/time display does not tell you how the OS is set.

Code: Select all

$ timedatectl status
      Local time: Sat 2016-12-31 10:03:19 AEDT
  Universal time: Fri 2016-12-30 23:03:19 UTC
        RTC time: Fri 2016-12-30 23:03:19
       Time zone: Australia/Sydney (AEDT, +1100)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

LM18 has defaulted to UTC. LM18 is adding 11 hours to the date/time in the pictures. It is adding the 11 hours for both FAT and NTFS. Windows does not add the 11 hours for FAT and does not add the 11 hours when copied from FAT to NTFS. I will boot Windows to see how that is set.

[Petermint]

The hardware, BIOS, shows UTC. Windows is the same as the LM Date/Time display, it does not tell me what it is doing internally.

I copied two files to the shared NTFS partition. A file created in LM 18 displays as the UTC time, not the local time, 6 am instead of 5 pm. A file copied from SD to NTFS to Ext4 and back shows the correct time. LM 18 is maintaining the original time but adding 11 hours on display. Windows 8.1 is displaying the actual time recorded for the file.

Windows is doing the right thing for pictures. LM 18 is wrong. Assuming UTC is wrong because the time displayed for the file will vary when I change time zones. A sunrise photograph will be listed as a lunchtime or night time photograph depending on the time zone I am in when browsing the photographs.

How do I change LM 18 to display the actual time, not some fake time?

[rene]

Let me assure you that Mint does not generally have any such problem; that we are looking at a specific issue here. More or less so: the "SDCARD timestamp issue" is very much standard on localtime/systemd systems and I may have as such jumped to the conclusion that indeed you were using localtime. If it wasn't applicable in this case I'd consider that rather unexpected but you have now (finally) confirmed that it is a dual boot system, through the timedatectl output that as far as Mint is aware your RTC is kept in UTC now, and that you have a correct timezone set.

With the RTC in UTC the systemd synchronisation issue w.r.t. FAT is N/A and certainly the issue is N/A for NTFS. At the moment the only thing I can think of is you likely have not told Windows that your RTC is in UTC. That it is interfering by synchronizing NTP-obtained time back to the RTC in localtime. Linux then boots and obtains said localtime from the RTC but assumes it's UTC. I would've expected that you would notice this from an actual incorrect clock but perhaps that a relatively late NTP synchronisation during the Linux boot hides the issue from immediate sight.

Whatever the precise problem path may be here, certainly it is the case that indeed you will need to tell Windows that your RTC is in UTC if indeed it is. Please refer to https://wiki.archlinux.org/index.php/ti ... in_Windows. And note that the converse route of setting Linux to localtime would leave you with that systemd/fat issue; that keeping the RTC in UTC and telling Windows such is much preferred. I would set the above registry key, reboot into the BIOS and make sure it is displaying correct UTC time, boot into Windows and test, reboot into Linux and test.

If you after doing that find there to be still a problem I expect I will need to give up, but do in that case also verify that "echo $TZ" in Linux returns nothing.

[Petermint]

echo $TZ returns nothing.
Both Windows and Linux display the correct time. There are no time changes when booting from one OS to another.
I tested

Code: Select all

timedatectl set-local-rtc 1

. It changed /etc/adjtime as described in the documentation but nemo still displays the file date/time wrong.

Bah!!! I want to see the file date/time, not what it might be in another time zone.

[Petermint]

A quick boot around Linux, BIOS, Windows, BIOS, Linux. The hardware clock is showing the correct time. Everything works there.

Nemo still shows the correct date/time for old images and the wrong date/time for new images. I will take some new photographs to see what happens.

[Petermint]

Fixed!
I created a new photo and copied it into the computer. The date/time is correct.

[Relative]

Exactly how did you fix it? Tried to follow everything in this thread and still have the problem. Routing pictures through Windows is still my only viable solution.

Mike

[Petermint]

Exactly how did you fix it?

I used

Code: Select all

timedatectl set-local-rtc 1

to fix the date/time for new files. It did not change the date/time on existing files which means the ones with the wrong date/date remain wrong.

[Relative]

timedatectl set-local-rtc 1
Failed to issue method call: Input/output error

That's the error message I get after entering that argument.

Thought that maybe might be the letter 'l' instead of the number '1' so tried:

timedatectl set-local-rtc l
Failed to parse local RTC setting: l


Mike