fix(web): wrong timeline timezone

[antoniosarro]

Fixed #15634

• Fixed the fromLocalDateTime function which forced the use of the UTC zone instead of the local one, which caused misalignments in the display of data especially close to midnight (some images from the current day were displayed as from the previous day or vice versa)

I tested it using different timezones and uploading photos with a date with which I could replicate the bug, and it seems to have been fixed.

The fromLocalDateTime function is also used in other files besides the timeline ones, so I think that if this date inconsistency was present there too it has been resolved.

[github-actions]

Label error. Requires exactly 1 of: changelog:.*. Found: . A maintainer will add the required label.

[jrasm91]

The localDateTime is a special field which represents the "local time" the picture was taken. It's always stored as UTC, regardless of the timezone the picture was taken in. For example, a picture taken at 5am Eastern is stored in this column as 5am UTC

[antoniosarro]

So if I understood correctly from your comment, when saving in the db for example 8am EST is not saved 1pm UTC but 8am UTC.

But at this point, if the user then decides to change timezone because he moves the server or something similar, how does the correct conversion for the new timezone happen if the saved UTC is not the correct one?

The change I made is because I thought that in the db there was the correct UTC date as localDateTime, and therefore after the retrival I went to convert it back into the correct timezone that the user was using.

Tell me if I understood your explanation correctly and thanks for the trouble

[jrasm91]

Yes that sounds correct. Specifically, for the timeline, we want to be able to find assets taken "on new years eve". If you have pictures on new years in different timezones they should all be displayed on the same day, December 31st, regardless of the timezone.

We do this by taking 5pm Eastern, converting it to 5pm UTC and sorting it in the database. Now all the records have the same timezone and can be easily chunked into correct groups.

[jrasm91]

We store the timezone in exif.timeZone and also exif.dateTimeOriginal has the timezone aware date as you would expect to see.

Also moving the server or changing its thimezone doesn't change when a picture was taken so nothing else needs to be adjusted

[antoniosarro]

So the bug in the issue is expected behavior. At this point it would be useful to warn the user of this behavior and perhaps add some settings that allow you to switch from the current display behavior (unified timezones) to the "classic" one (mixed timezones).

I'll continue the discussion in the issue so as not to weigh it down here