Odd. We just adjusted clocks forward one hour for Daylight Savings Time here. Opening dt, and it flagged all my xmp files as being 1 hour different than the database. Nothing had changed in anything since yesterday, except the computer’s clock update…
Not a big deal, but curious if this has happened to anyone else?
Usually the change to DST is done automatically (by tools of your OS and by accessing a special internetserver). If you do it manually you should possibly not adjust time but just setting the DST flag.
Edit : personally I never changed time manually, always kept time synchronized automatically with internet server for my time zone (Central European Time, CET). Never had to manipulate the setting for DST. Never had any issues with dates / times in darktable in this context .
Computer changed itself automatically just fine. Darktable, on startup brought up it’s “somethings changed” synch window. The darktable database and the timestamps on all the xmp files were different by exactly 1 hour. Had to wait for darktable to update the 15,000 entries in the database…
Had to wait for darktable to update the 15,000 entries in the database…
Why would you want a switch to/from DST to change entries in the database?
I wonder what happens during a DST switch with the hardware clock set to local time (and not UTC)…
Just try and see what happens. I remember using the tool timedatectl to manipulate my hardware clock.
Manipulating the hardware clock is easy enough.
But so far, all we have is a statement of the visual problem, no info at all about @TSANDER 's system.
That makes any attempt to find a solution a bit like gazing into a crystal ball.
Almost my question…more accurately it would be: “Why would a system time change provoke a mismatch between the timestamp of a file, and the same information recorded in the database?”
System time shouldn’t enter in to the synch comparison at all.
Rather than potentially see this synch warning come up every time I started dt, it seemed better to just tell it to change entries. Maybe it will happen again this fall when we drop back.
This is a Windows system (Win 10), so playing with timedatect1 doesn’t seem like it would be productive.
Yes, I’m assuming it was the system time change that kicked off the synch dialog. Unlikely the timestamp of all the 15,000 files got changed by exactly one hour. So either the database itself changed…or something in the synch routine itself is using system time, and biased the time shown as “database time” in the synch display.
Since there appear to be no other reports of this, unlikely to warrant much further exploration.
I’m on Windows and my system time switched due to DST this weekend. I did not get any flags for xmp. What version of darktable are you running? Did you manually changed the time or it was done automatically?
3.8.1
System time changed automatically.
'Tis a mystery…
I remember noticing something like this in the past myself with previous versions of dt. I haven’t opened dt since switching to DST This past weekend.
@TSANDER where are your xmps located? On a disk in your Windows PC, an external disk or on a NAS?
Do you know which filesystem that disk is using (NTFS, FAT32, etc)?
In my case I’m sharing the same photos folder, that’s located on a NAS and mounted via SAMBA/SMB on several machines:
- Desktop with Ubuntu & Windows (dual boot) - the system RTC is set to UTC and Windows has a registry setting to expect just that.
- Laptop with Windows 10 and the system RTC is (most likely) in local time.
- the NAS is running Linux and the filesystem is EXT4, therefore the modification timestamps are surely in UTC and on the fly converted to local time.
I don’t remember from the last time, in which order I’ve opened my various darktable installations and which one then triggered having to update-database-from-xmp.
But once I’ve done that on one of them, I believe I had to do it on all subsequent dt installations, but I could be wrong about that.
1 Like
Files are on a separate local hard disk (“D:”) as well as the database files, while program files are on the C: drive. Everything using NTFS. Everything using local time.
A change in system time as such would likely not do that. The DST flag and/or timezone would be my prime suspects.
Could be that one of the two timestamps involved in the comparison has no timezone information, or doesn’t get it applied. In that case, even when the numerical values are the same, with DST active, one would be 1h off after application of the timezone data…
More far-fetched: the file timestamps get timezone info applied twice: once from the filesystem when dt asks for it, once by dt (who sees a timestamp with timezone info, where that info shouldn’t be present).
To figure such things out, the sign of the observed difference would be useful (all we know so far is “there’s 1h difference”), and some knowledge of how dt and ms-windows handle timestamps.