Database timestamp seems to be zero

Software darktable
1

I have darktable configured to detect changes in xmp files (to sync tags and other metadata added via other applications), so I regularly get the updated XMP sidecar files found window at start up. I typically just select everything there and click keep the XMP edit and this seems to work well.

However, I recently noticed that in these situations, the “database timestamp” is always 01 Jan 1970 (I guess the timestamp is zero), while the XMP has the correct date:

image

While it’s not a big deal, I’m wondering why this is the case. Does it indicate some issue with my system?

I haven’t verified for sure but I think I always get this when adding new images and then restarting darktable (even if there was no external change to the xmp), so it seems they are always added with timestamp zero and only set to the proper time after the restart when syncing with the xmp.

2

Which version of darktable ?
Which OS and version ?
What kind of images ? JPG, RAW, other ?
How do you import the images ?

3

Sorry, forgot to add that information.

  • darktable 4.2.1
  • Ubuntu 22.04.2
  • Raw files
  • Imported via add to library…

I just noticed that I also seem to get this for images that were added previously but only edited now (i.e. after restart of darktable it shows updated sidecar files for these images, with an outdated database timestamp (not zero in this case but probably from when I added them). So it seems darktable does also not update the timestamp in the database if it is later modified.

4

How did you install? Snso, flatpak, self compiled, etc?

5

self compiled (from the release-4.2.1 tag)

6

Hm, I cannot intentionally replicate it for already added images right now, so not sure what exactly is triggering it.

7

Moinchen, Felix!

I cannot say whether it’s a clue, or not, but
XMP timestamps are in CEST,
your dt timestamps are in CET.

Does 'buntu have timedatectl?
If so, what does it report?

Have fun!
Claes in Lund, Schweden

8

Good catch. Here is the output of timedatectl:

               Local time: So 2023-04-16 17:33:53 CEST
           Universal time: So 2023-04-16 15:33:53 UTC
                 RTC time: So 2023-04-16 15:33:53
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

However, a mere timezone issue wouldn’t explain why the timestamp in the database is zero (aka 1.1.1970), so not sure if that’s the problem.

9

I never observed a behavior you are describing. Is it possible that the buffer battery of the real time clock is empty? And that maybe at the time of the import or the editing no NTP service was available for synchronization? Could this explain why unix epoch 0 was entered in the database? But actually, the clock should still run at power-on and provide a time just above unix epoch 0. Kind of mysterious.

It is a SQLite3 database (.config/darktable/library.db). The table images contains the columns write_timestamp, import_timestamp, change_timestamp, export_timestamp and print_timestamp. I would take a closer look at these columns, maybe you can find a systematic.

10

I have fixed many issues on this part recently. Will be part of 4.4. See RELEASE_NOTES:

  • Fix crawler when updating the XMP. The XMP file must be set with the
    timestamp of the database entry to ensure we don’t have continuous
    mismatches reported.

and

  • Make sure the database timestamp is always set when possibly writing
    a sidecar xmp file.

If you still have issues with that when 4.4 is out please report on GitHub.

11

Great to hear! I’ll wait for 4.4 then and see if that fixes things :slight_smile: