The two datetime widgets are because one is "UTC" and the other "UnixTime" , i will add different names for them.

the image date is usually taken from the exif timestamp. does the exif timestamp of the jpeg file not match the filetime? it looks ok here curently with the 100D

The EXIF timestamp does not match the timestamp of the file. Here are the timestamps from various programs.

# mediainfo -F image.jpg
File last modification date              : UTC 2015-12-05 17:13:20
File last modification date (local)      : 2015-12-05 12:13:20

# EXIF.py image.jpg
EXIF DateTimeDigitized (ASCII): 2015:12:05 17:13:19
EXIF DateTimeOriginal (ASCII): 2015:12:05 17:13:19

# stat -x image.jpg
Access: Thu Dec 24 20:32:53 2015
Modify: Sat Dec  5 12:13:20 2015
Change: Wed Dec  9 22:17:24 2015

I've just started using gphoto2 on Arch Linux, gphoto2 2.5.6-1, libgphoto2 2.5.9-1. The modification time of the JPEGs almost matches the EXIF, but is consistently one or two seconds too early; none of the 33 photos I've just extracted have a spot-on mtime. All of the incorrect mtimes set by gphoto2 are even; not a single one is odd, as some should be.

$ stat -c %y 4523.img.jpg
2016-02-15 13:39:36.000000000 +0000
$ LC_ALL=C grep -oa '20[0-9][0-9]:[0-9][0-9]:[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]' 4523.img.jpg |

uniq -c
3 2016:02:15 13:39:37

Here, the mtime on the file is one second too early.

Forgot to say, you can see a similar drift in @scfarley's last comment above. EXIF.py is saying 17:13:19, but stat shows 12:13:20. Ignore the hours being adrift, that's understandable, but the seconds are one out.

I'd always assumed the EXIF data contains the time the photo was taken but the file date is when it was saved to the memory card. Depending on the speed of the card, the time to compress, any other in-camera processing (e.g. dark subtraction), accumulated unsaved files etc. this could be several seconds after the picture was taken.

@jim-easterbrook, that would make sense, but I'm seeing the EXIF be 1 or 2 seconds later than the mtime, not earlier.

That the Unix mtime set by gphoto2 is even is probably due to the FAT filesystem used by the Canon only having even-second granularity in its timestamps. But that would only explain the mtime being one second earlier than the EXIF due to rounding down to the previous even second, not the two seconds that also often occurs.

What's the source of the Unix mtime set by gphoto2? Part of the PTP protocol? Given the filesystem's even-only limitation, and that the JPEG forever more carries the EXIF timestamps, isn't gphoto2 on a losing wicket by not using the EXIF times given that's what's displayed by Properties, etc., and will compared with the mtime?

What time stamps do the files have if you put the camera's memory card directly into a computer? (I.e. no gphoto2 involvement at all.)