Incorrect taken time in images

[grenzverkehr]

"ExifIFD:DateTimeOriginal" is used as the taken time. This tag is in local time. However, Nextcloud handles the date-time information as if it were in UTC. So 13:07:44 is displayed instead of 11:07:44.

[U-go-a]

I may be seeing a related issue, but in my case it affects Photos month grouping rather than only the displayed taken time in the viewer/details sidebar.

Environment:
Nextcloud snap
Nextcloud version: 32.0.8.2
Photos app version: 5.0.0
Image type: JPEG, originally from an iPhone
Server timezone: JST / UTC+09:00

The file is correctly located in the Files tab under the November 2025 folder:
Photos/2025/11/25-11-30 16-43-51 IMG_6519.jpg

The EXIF metadata verified with exiftool is:
DateTimeOriginal : 2025:11:30 16:43:51
CreateDate : 2025:11:30 16:43:51
ModifyDate : 2025:11:30 16:43:51
OffsetTimeOriginal : +09:00
OffsetTime : +09:00
Orientation : 1

After setting the metadata, I regenerated metadata with:
sudo nextcloud.occ files:scan --path="UserName/files/Photos/2025/11/25-11-30 16-43-51 IMG_6519.jpg" --generate-metadata

Expected behavior:
Since the timestamp is 2025-11-30 16:43:51 +09:00, I expected the photo to be grouped under November 2025 in the Photos tab.

Actual behavior:
In the Photos tab, the image appears under December 2025.

When checking around the month boundary, I observed:
November 2025 group: up to around 2025-11-30 12:52
December 2025 group: starts from 2025-11-30 16:43

This seems consistent with the possibility described in this issue: EXIF local date-time information may be handled as if it were UTC.

In my case, the problem is not only the displayed taken time, but also the Photos tab date/month grouping near a month boundary.

I am not sure whether this belongs here, in nextcloud/viewer, nextcloud/photos, or in the metadata generation logic, but I thought this might be useful as another data point.

[U-go-a]

I traced one affected image through the Nextcloud Photos metadata pipeline, and the timezone error can be reproduced exactly.

The source image contains:
DateTimeOriginal 2025:11:30 16:43:51
OffsetTimeOriginal +09:00

PHP used by the Nextcloud snap reads the relevant EXIF fields as:
DateTimeOriginal => 2025:11:30 16:43:51
UndefinedTag:0x9011 => +09:00

0x9011 corresponds to OffsetTimeOriginal.

In apps/photos/lib/Listener/OriginalDateTimeMetadataProvider.php, however, only DateTimeOriginal is used:

$rawDateTimeOriginal =
    $metadata->getArray(ExifMetadataProvider::METADATA_KEY_EXIF)['DateTimeOriginal'];

$timestampOriginal =
    $this->dateToTimestamp('Y:m:d G:i:s', $rawDateTimeOriginal, $node);

dateToTimestamp() then calls:
DateTime::createFromFormat($format, $date);
without specifying a timezone.

In the Nextcloud snap environment, PHP's default timezone is UTC. Therefore:
2025:11:30 16:43:51
is interpreted as:
2025-11-30 16:43:51 UTC
Unix timestamp: 1764521031

This exactly matches the value stored by Nextcloud:
photos-original_date_time = 1764521031

However, the EXIF data should be interpreted as:
2025-11-30 16:43:51 +09:00
Unix timestamp: 1764488631
UTC: 2025-11-30 07:43:51

The difference is exactly:
32400 seconds = 9 hours

Therefore, the timestamp stored by Nextcloud corresponds to:
2025-12-01 01:43:51 JST

This explains why a photo actually taken on Nov 30 at 16:43 JST can be grouped under December in Photos.

The source code already contains this comment:
// Note: We do not have the timezone when parsing the date,
// so the timestamp will be off by X hours.

In this case, however, the timezone information is present in the EXIF data and is read by PHP. PHP exposes OffsetTimeOriginal as UndefinedTag:0x9011, but OriginalDateTimeMetadataProvider does not use that value when generating photos-original_date_time.

So the incorrect timestamp appears to be generated in OriginalDateTimeMetadataProvider, rather than in Viewer itself.

This also appears to explain the related Photos issue nextcloud/photos#3592.

[U-go-a]

I submitted a pull request to nextcloud/photos with a fix for the case where EXIF OffsetTimeOriginal is available:

nextcloud/photos#3849

The change preserves EXIF tags 0x9010/0x9011/0x9012 as OffsetTime, OffsetTimeOriginal, and OffsetTimeDigitized, and uses OffsetTimeOriginal together with DateTimeOriginal when generating photos-original_date_time.

For the example I traced above:

DateTimeOriginal: 2025:11:30 16:43:51
OffsetTimeOriginal: +09:00

the stored timestamp changes from:

1764521031

to:

1764488631

Unit tests were added, and the full Photos PHPUnit suite passes.

This addresses the issue for images that contain a usable OffsetTimeOriginal.