Time stamp discrepancy between Canon and Linux computer

[Dazz1]

I just noticed a time discrepancy between my Camera and my laptop.

The Camera is a Canon 80D and is set to the correct time and the Timezone is Sydney (because I can't find Brisbane on it's popup list).

The laptop is running Ubuntu Studio and it's time is correct as well, and the timezone is set to Brisbane.

I am seeing a 10 hour difference. A file of a picture taken on the camera, shows as 10 hours in the future when the SD Card is plugged into the computer. It's 10 hours, so not a daylight saving thing or anything like that.

[ameerat42]

It's the difference between GMT and AEST. Could the camera somehow be set to GMT?

[Dazz1]

It's the difference between GMT and AEST. Could the camera somehow be set to GMT?

Yep, it has to be something to do with the 10 hour time offset, but the camera is set correctly. I just checked, and the Exif data has the correct time in it, so it's just a FAT file timestamp problem. There's at least 3 of them, last time accessed, changed, and created - maybe more The camera appears to do weird things as access time seems to be always recorded as 10am and the creation date is blank. Only the change date/time seems to be recorded, and that's the one that's showing as 10 hours in the future.

Oh well, I guess I have to ignore the file stamps, and just use the Exif data.

[ameerat42]

Only other thing that falls into the head is that Linux is displaying them unexpectedly.
Can you (somehow) check how it is doing that? Can you set it to display as GMT in the
settings somewhere?

[Dazz1]

Only other thing that falls into the head is that Linux is displaying them unexpectedly.
Can you (somehow) check how it is doing that? Can you set it to display as GMT in the
settings somewhere?

\\Well, you can stat the files. Here I have 2 files, one, IMG_0036.CR2, is straight from the camera. IMG_0035.CR2 has been 'touch"ed in linux to correct the time.

stat *  File: IMG_0035.CR2
  Size: 31302264      Blocks: 61184      IO Block: 32768  regular file
Device: b309h/45833d    Inode: 486         Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  myuser)   Gid: ( 1000/  myuser)
Access: 2018-07-01 10:00:00.000000000 +1000
Modify: 2018-07-01 13:06:52.000000000 +1000
Change: 2018-07-01 13:06:52.000000000 +1000
 Birth: -
  File: IMG_0036.CR2
  Size: 30177451      Blocks: 58944      IO Block: 32768  regular file
Device: b309h/45833d    Inode: 487         Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  myuser)   Gid: ( 1000/  myuser)
Access: 2018-07-01 10:00:00.000000000 +1000
Modify: 2018-07-01 23:09:04.000000000 +1000
Change: 2018-07-01 23:09:02.000000000 +1000

The camera is definitely doing something odd. Just look at the output of ls -al. The file from the camera only has a date listed, and no associated time. I think it does this with a file that has a future time however.

$ ls -altotal 60128
drwxr-xr-x 2 myuser myuser    32768 Jul  1 13:10 .
drwxr-xr-x 4 myuser myuser    32768 Jul  1  2018 ..
-rw-r--r-- 1 myuser myuser 31302264 Jul  1 13:06 IMG_0035.CR2
-rw-r--r-- 1 myuser myuser 30177451 Jul  1  2018 IMG_0036.CR2

[Tannin]

It is showing an ACCESSED time TEN hours in the FUTURE.

This tells us three things.

(1) The access time is computer-related. When you view or copy a file, that is an "access".
(2) Ten hours is the difference from GMT. Look for computer problems rather than camera problems. There is no reason why your camera would decide to add ten hours instead of two or seven, but there is an obvios reason why your computer would - you set it to +10 yourself.
(3) Something is converting from GMT TWICE. That is PLUS ten hours, not minus. Something (your computer) is adding ten hours to a time that has already had ten hours added to it.

Ergo, it's the computer's fault.

Unlike most other computers, Linux computers are designed to be set to GMT, no matter where in the world they are. They then add or subtract a correction to get local time. This is not a fault, it is a design choice. Your computer is adding ten hours to the camera time because it thinks it's in Sydney and it thinks the other time is GMT.

The correct answer is probably to set your motherboard clock to GMT.

[Dazz1]

It is showing an ACCESSED time TEN hours in the FUTURE.

This tells us three things.

(1) The access time is computer-related. When you view or copy a file, that is an "access".
(2) Ten hours is the difference from GMT. Look for computer problems rather than camera problems. There is no reason why your camera would decide to add ten hours instead of two or seven, but there is an obvios reason why your computer would - you set it to +10 yourself.
(3) Something is converting from GMT TWICE. That is PLUS ten hours, not minus. Something (your computer) is adding ten hours to a time that has already had ten hours added to it.

Ergo, it's the computer's fault.

Unlike most other computers, Linux computers are designed to be set to GMT, no matter where in the world they are. They then add or subtract a correction to get local time. This is not a fault, it is a design choice. Your computer is adding ten hours to the camera time because it thinks it's in Sydney and it thinks the other time is GMT.

The correct answer is probably to set your motherboard clock to GMT.

Unfortunately, it IS set to GMT in the BIOS.

The other thing is that linus was manually set to the current time. i.e. I typed it in, it didn't read that from the BIOS. I have also tried setting the computer to synchronise with ntp time servers.

[Dazz1]

It is showing an ACCESSED time TEN hours in the FUTURE.

This tells us three things.

(1) The access time is computer-related. When you view or copy a file, that is an "access".
(2) Ten hours is the difference from GMT. Look for computer problems rather than camera problems. There is no reason why your camera would decide to add ten hours instead of two or seven, but there is an obvios reason why your computer would - you set it to +10 yourself.
(3) Something is converting from GMT TWICE. That is PLUS ten hours, not minus. Something (your computer) is adding ten hours to a time that has already had ten hours added to it.

Still trying to understand this.

Firstly, it's the modified and changed times that are showing 23:09 and that was in the future.

Theoretically, If the camera writes the actual local time, then the computer reads it and expects it to be GMT, of course it will add 10 hours to it - but it's the camera that wrote the wrong time.

- - - Updated - - -

So here's the latest. It is a bug that's been seen before. https://ubuntuforums.org/archive/ind...t-1234471.html and https://bugs.launchpad.net/ubuntu/+s...ux/+bug/426886

It says the bug was fixed, but since I am seeing it, maybe it has crept back in.

Basically the workaround is to tell linux to work in local time not UTC, then set the RTC/BIOS to local time. The linux command now (for systemd) to use local time is

timedatectl set-local-rtc 1 --adjust-system-clock

then of course, set the BIOS clock appropriately.

Funny thing happened though, I had to re-mount the SD-card before the time corrected itself.