Metadata: Add TakenAtLocal to YAML backup files

[stegatxins0]

1. What is not working as documented?

I try to recover my backup (I have the storage and the original folder) but after indexing, I realize that the date/time is incorrect. Upon investigation, I find that photoprism incorrectly show the UTC time as the local time.

https://streamable.com/on2a2b

2. How can we reproduce it?

Steps to reproduce the behavior:

1. Change time of an image to 00:25, timezone GMT +8
2. Reset the database
3. Index
4. See error

3. What behavior do you expect?

Expect to see 00:25 GMT +8, see 16:25 GMT +8 on the previous date instead

5. Can you provide us with example files for testing, error logs, or screenshots?

Here's the image and the yaml sidecar used in the video.
test.zip

6. Which software versions do you use?

(a) PhotoPrism Architecture & Build Number: AMD64, Build 21118-e58fee0fb
(b) Database Type & Version: mysql Ver 15.1 Distrib 10.10.3-MariaDB
(c) Operating System Types & Versions: WSL2 on Windows 10

[lastzero]

Please run exiftool -g -n -j filename to check the picture metadata before opening metadata related bug reports and include the complete output. Thank you!

[stegatxins0]

Apologies here is it

[{
  "SourceFile": "images.png",
  "ExifTool": {
    "ExifToolVersion": 12.52
  },
  "File": {
    "FileName": "images.png",
    "Directory": ".",
    "FileSize": 1165,
    "FileModifyDate": "2023:04:11 00:25:59+08:00",
    "FileAccessDate": "2023:04:11 01:56:23+08:00",
    "FileInodeChangeDate": "2023:04:11 01:56:20+08:00",
    "FilePermissions": 100777,
    "FileType": "PNG",
    "FileTypeExtension": "PNG",
    "MIMEType": "image/png"
  },
  "PNG": {
    "ImageWidth": 225,
    "ImageHeight": 225,
    "BitDepth": 8,
    "ColorType": 3,
    "Compression": 0,
    "Filter": 0,
    "Interlace": 0,
    "Palette": "(Binary data 114 bytes, use -b option to extract)"
  },
  "Composite": {
    "ImageSize": "225 225",
    "Megapixels": 0.050625
  }
}]

[lastzero]

So the actual file doesn't have any metadata and you probably also didn't have a full backup, only the YAML sidecar file which you used to restore a manually changed date? Seems possible there's a glitch if you didn't added any location info along with it.

We are out of the office until end of the week and can't check the zip file on the phone.

[stegatxins0]

So the actual file doesn't have any metadata and you probably also didn't have a full backup, only the YAML sidecar file which you used to restore a manually changed date? Seems possible there's a glitch if you didn't added any location info along with it.

Yes unfortunately I only have the YAML sidecar and when I try to restore it the date is incorrect.

[lastzero]

My commit adds the TakenAtLocal value to the YAML backup files, which should prevent incorrect times in the future.

In your case, I assume that TakenAt is restored from the backup and the TakenAtLocal time is automatically set during indexing based on the filesystem mod time. After that it is ignored because the difference to TakenAt is too big. But since it is also not empty, the TakenAt time is now considered as local time and changed to UTC, even though it was already in UTC. So this is a rather special case which can only occur if the original file does not contain any time information and manual changes are made.

[graciousgrey]

I can confirm that it works now 👍

[stegatxins0]

Yes it's working right now. Thank you very much!! (though I'll have to manually adjust the dates of my old pictures affected by this bug, will make sure to keep an actual backup next time)