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
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
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.
I assume that there is some exit tag that specifies DST and darktable is trying to correct for that.
If you can post a raw file that exhibits the problem, that’d be great
2020-08-23T20_29_48_Zaton_DSC_7576.NEF (26.8 MB)
This is one example. It was taken at 19:29:48. Err … please don’t comment on the artistic value.
The relevant part of the EXIF data looks like this:
Sounds like the bug #5802 fixed with #5877 (=> dt 3.4).
Yes, this seems to be the same problem. The problem description in bug #5802 sounds discomfortingly familiar.
Will I have to wait for 3.4 to come out, or can I get this fix from one of the OBS versions – " snapshots from the stable release branch" or snapshots from the master branch"?
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
— what output does it give you?
Also: do you happen to have Windows somewhere on that machine?
Claes in Lund, Sweden
The computer’s clock is set to local time. Here’s the output from
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 …
No, do not touch Win!!!
It is much easier to mend things in Linux.
Let’s hope dt 3.4 will solve the problem for you.
Claes in Lund, Schweden
@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.
Not sure British time will be better. The current Brazilian time, we are in winter, does not suffer this issue.
Sounds right as 3.4 preparation may already be a bit short.
I’ve followed one of the offered solution:
Reg add HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_QWORD /d 1
and I’ve got rid of my dual boot time issue…
There is no plan for a 3.2.2 indeed.
Fair enough, given that 3.4 is around the corner. I’ll then just have to tweak the system time setting (DST, time zone) for the time being.
Hmm, Brazil is a bit far for me, just to get the file names right and also flying isn’t too attractive in times of COVID-19.
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…