Improve sorting of photos

[MMauro94]

Hello everyone! First of all thanks for all the effort you put into this software, it's really great. I'd like to show you a problem I have and propose a possible solution.

The Problem

I'm often in this situation:

• Open camera
• Shoot first few photos: they have no geo information available (GPS hasn't got a fix yet)
• Shoot some more photos: now those get tagged with geo data

The problem I'm facing is that the first photos are completely out of order wrt the others. This is because the default timezone of the server is being used for the first ones, while the actual timezone derived from gps data is used for the others.

Setting the "correct" timezone for the server, however, is very problematic. In my case:

• Some photos have been shot on vacation, in a different timezone than the server
• Most of my photos have been shot in my home country, while I've recently moved to a different country in a different timezone

The solution

Option 1

My proposed solution is to split the exif.dateTimeOriginal DB field in two:

• dateTime will be of the postgres type timestamp: this contains just the date and time, without the timezone (basically a LocalDateTime for those familiar with Joda time/Java APIs)
• timezone: just the timezone. This could be an offset (int) or even a ZoneId like Europe/Rome, etc.

This allows, in my opinion, for a lot of things to "fall into place":

• The sorting on the timeline can now be done only on the date/time field. I know that this is not technically correct (in the sense that it would be better to sort with the timezone), but people tend to shoot photos in a LocalDateTime-monotonic way anyway, and it avoids a lot of this kind of issues.
  • Yes, there is the edge case in which a person shoots a photo in a timezone, immediately takes a plane, lands on a "lower" timezone and shoots another one, and they would be out of order (assuming that the flight took less than the offset difference). This is however a pretty extreme edge-case, and could be rectified if both photos have a timezone with some tinkering with the sorting algorithm.
  • This could also be an advanced user/server customizable option if needed: either sort with the TZ or don't
• It allows the timezone field to be nullable in case there is no information about it, so we don't fill the DB with a "random" default value that can always be used at runtime if needed. This also allows changing the default timezone without having to re-extract all metadata
• It allows the UI to better show the information the server has: the local date time will always be shown, while the timezone can be shown only if that information is available.

Option 2

Another option to fix the same problem would be to fix the heuristics of the guessing of the timezone based on photos shot close in time. For instance, if I have these photos:

• A. 2023-08-24 10.00.00 (no gps data)
• B. 2023-08-24 10.00.01 (dublin)
• C. 2023-08-24 10.00.10 (dublin)
• D. 2023-08-24 10.10.15 (no gps data)

We can safely assume that the user didn't teleport to another country in the span of 10 minutes and extrapolate the TZ for photos A and D.

I'm just mentioning this option as a possibility, but I don't really like it because:

• It makes the metadata extraction not an isolated process as it would have to look at other assets, which is hard to reason about and introduces some complexities
• It still doesn't fix the problem of assuming a timezone for those "lonely" photos without gps data
  • This is particularly problematic for people who:
    • moved in a different timezone once or multiple times in their lives and have to run the initial import of loads of photos
    • travel often in different timezones, so a fixed "default" timezone on the server is not gonna cut it
  • Plus we'd might show an incorrect timezone in the UI

Option 3

Last thing that comes to mind is for each user to be able to set in which timezone they've been in for certain periods. For people who don't travel super often, this might be an easy thing to setup:

• Set a default (home) timezone
• Set "overrides" for travels and past residences

For most people this would be a very short table with one home timezone and a few entries for each one of their travels in a different TZ.

This way whenever a timezone is needed, this information can be looked up easily.

This could also be automagically assumed based on aggregated geo information of the library, similarly to what's described in Option 2.

---

My personal preference is Option 1, as I find it the best way to deal with this kind of things.

Of course, things could also be mixed. For instance, separate the fields as in option 1 but use the lookup table in option 3.

I'm curious to hear your thoughts about this and hopefully reach a consensus on what's the best course of action :)

Thanks,
Mauro.

PS: slightly unrelated, I have another (easier) sorting problem with scanned analog photos: since I don't know exactly the day/time in which they where shot, I've just put a date like 1994-10-10T10:00:00Z. It would be nice to order based on the original filename if the order date/time are identical.

[DeltaTango69]

I assume there is a bug in immich. Normally for pictures the exif entry datetimeoriginal is used for sorting. This entry is stored only in local time. There is no information of timezone. Many cameras have no gps and so the offset time is not known. Older pictures has no gps data and the only information of the taken time is the local time stored in the exif data datetimeoriginal. For MP4 the createdate can only be stored in UTC time. The server software has to calculate therefore the time difference that the timeline between photos and videos is correct. Otherwise the timeline were a total mess. I have found out actually that there is a time difference between photos with gps data and without, because the offset time is somehow calculated. In my opinion this is wrong and only the datetimeoriginal should be used for the local time. So Windows and other programs (plex, Google.......) handle the data

[akoen]

@MMauro94 and @DeltaTango69 I started a Discord focus discussion on this point here: https://discord.com/channels/979116623879368755/1206309678578016277/1206309678578016277, because I agree with your points. Your input would be super appreciated.

[chicocheco]

Yes, I believe it is a bug. I have hundreds of photos that are are sorted and presented as if they were taken 1 or 2 hours later than they actually were. Is it trying to add timezone or something?

What is curious that it doesn't happen with photos taken by a smartphone. These are fine. If I didn't have some albums where both cameras and smartphone photos were mixed together, I would not even care much.

I have 2 photos, one from smartphone and other from a camera taken, say, at 14:04. Everything seems to be correct in EXIF data of the one taken by a camera and still, Immich says it was taken at 16:04 GMT + 02:00. The smartphone displays 14:05 GMT + 02:00, all correct. I can even provide some exiftool output to prove it.

When I download both photos into my iPhone directly from Immich, they both show 14:04. It is a mystery for me.

[fwsmit]

I'm working on resolving the issues with timezone detection for DSLR pictures. At least on my Sony A7 first gen it's possible to infer the timezone from the exif metadata. To fix this issue for other camera's as well, I need some example pictures.

To submit example pictures, please follow the following steps:

• Set your camera to a time of 10:00 AM and a timezone of GMT+0 (No daylight savings time). Take the first picture.
• Set your camera to a timezone of GMT+8 (No daylight savings time). The time should now be 18:00. Take the second picture

Upload both pictures to the following github issue: photostructure/exiftool-vendored.js#187. Please document clearly which image is which timezone and which camera you used.