Maybe I’m just doing something stupid. If so, please let me know …
I’m trying to now use only darktable (3.2.1) for handling my entire workflow. Previously I’ve been using digikam to import, tag and manage the collection and only used darktable for raw → jpeg conversion.
I’ve set up the darkable import to change the file names to $(EXIF_YEAR)-$(EXIF_MONTH)-$(EXIF_DAY)T$(EXIF_HOUR)_$(EXIF_MINUTE)_$(EXIF_SECOND)_$(JOBCODE)_$(FILE_NAME).$(FILE_EXTENSION).
It works as intended, except that there is a one hour difference between the time the picture was taken and the time in the resulting file name. The file name is +1 hour. I have set my camera (Nikon D750) to daylight saving time, if that matters; the time stamps (including those for original and digitized) in the EXIF data are correct, though.
Is this a bug, or am I doing something wrong here?
And how did you set the daylight saving?
On my camera (not a Nikon), there’s a menu setting to specify the time zone, including daylight saving (or not). If you just changed the time, and leave the zone as e.g. MET without daylight saving correction, the computer will see the time zone, and goes 'OK, camera does not apply daylight saving, I do, so I have to add one hour to the reported time to get the “clock time” ’
I’ve set the time zone to where I am, set daylight saving to ON and the time to my local time, i.e. with daylight saving applied.
Actually, l’ve set up dslrdashboard to sync the camera clock to that of my mobile every time I connect the two.
As I wrote before, the pictures’ EXIF data has the correct time. It’s just that darktable adds one hour when I use $(EXIF_HOUR) to compile a new file name upon import.
Actually, there can be another culprit hidden here… @mensch_plus_kamera: is your computer’s BIOS clock set to GMT/UTC or to local time?
Long time since I ran kubuntu, but doesn’t it have a command called
timedatectl
— what output does it give you?
Also: do you happen to have Windows somewhere on that machine?
The computer’s clock is set to local time. Here’s the output from timedatectl:
:~$ timedatectl
Local time: Di 2020-08-25 17:30:40 CEST
Universal time: Di 2020-08-25 15:30:40 UTC
RTC time: Di 2020-08-25 17:31:01
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
There is a Windows installation on this computer too, which typically doesn’t like the RTC being set to UTC. Maybe I should still do that and see if I can fix the Windows side. IIRC, there is some registry setting that has to be tweaked, so Windows works with a UTC RTC.
Still not sure, though, how the hardware clock should affect the value read from $(EXIF_HOUR). This is the time stored in the image metadata, not the computer’s system time.
In fact $(EXIF_HOUR) for naming imported file, uses directly camera original date time and doesn’t consider any other potential exif parameter.
If the computer is set on a time zone where there is saving daylight correction, (and potentially some other system parameters I do not know), dt is currently making the correction (on top of the exif already corrected time).
So the current workaround is to set your computer system time without saving daylight correction for importing your images.
After importing you set back your normal computer system time.
You may also disable the xmp update during importation as you may get some file timestamp discrepancy …
@Claes I found this article, which also advises against making Win10 use the RTC in UTC. Therefore, I’ll stick to my current setup, although the warning in the output of timedatectl makes me a bit nervous…
@phweyland Kubuntu only allows for selecting a time zone, but not to switch daylight saving time on or off separately. That is done automatically as a property of the selected time zone, I suppose. So I’d probably have to temporarily change to a time zone one hour behind CEST, i.e. British Summer Time (UTC+1).
There’s no plan for a dt 3.2.2 that fixes the issue, I guess.
Right !
BTW, you could choose a country in south hemisphere on the same longitude as yours and same time. This way even your xmp file timestamp would be correct.
… But Africa may not be very secure for covid neither…
