File creation date instead of Photo creationdate for photos with timezone offset +13:00

[gwensg35]

The bug

Hello everybody,
I am new to Immish and I wish to congratulate all of you for the great work.
I am now facing an issue with this 1.117 which was not noticed with 1.116.2
The date displayed in the detail of the photo is now the file creation date and not the photo shotting date anymore.



DSC_5115.exif.txt

The OS that Immich Server is running on

Ubuntu 24

Version of Immich Server

v1.117

Version of Immich Mobile App

1.116.1

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

#
# WARNING: Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.
#

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - 2283:3001
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, openvino] to the image tag.
    # Example tag: ${IMMICH_VERSION:-release}-cuda
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/redis:6.2-alpine@sha256:e3b17ba9479deec4b7d1eeec1548a253acc5374d68d3b27937fcfe4df8d18c7e
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    healthcheck:
      test: pg_isready --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' || exit 1; Chksum="$$(psql --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' --tuples-only --no-align --command='SELECT COALESCE(SUM(checksum_failures), 0) FROM pg_stat_database')"; echo "checksum failure count is $$Chksum"; [ "$$Chksum" = '0' ] || exit 1
      interval: 5m
      start_interval: 30s
      start_period: 5m
    command: ["postgres", "-c", "shared_preload_libraries=vectors.so", "-c", 'search_path="$$user", public, vectors', "-c", "logging_collector=on", "-c", "max_wal_size=2GB", "-c", "shared_buffers=512MB", "-c", "wal_compression=on"]
    restart: always

volumes:
  model-cache:

Your .env content

# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables

# The location where your uploaded files are stored
UPLOAD_LOCATION=./library
# The location where your database files are stored
DB_DATA_LOCATION=./postgres

# To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
# TZ=Etc/UTC

# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release

# Connection secret for postgres. You should change it to a random password
# Please use only the characters `A-Za-z0-9`, without special characters or spaces
DB_PASSWORD=Iourilb00

# The values below this line do not need to be changed
###################################################################################
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

Reproduction steps

1.Just Import jpg from local drive
2.Check the details of the imported photo
3.
...

Relevant log output

No response

Additional information

No response

[C-Otto]

Can you please share the unmodified file? You might be able to upload them here, otherwise we can exchange files over Discord or via mail.

[gwensg35]

Hi,
What is the unmodified file?

[C-Otto]

DSC_5115.jpg

[gwensg35]

[gwensg35]

I have noticed same behavior with much more other files

[C-Otto]

I found the issue, might be caused by an update of the library we use to read EXIF data.

[C-Otto]

[Microservices:MetadataService] Asset 9b7f0e5a-06cd-4cf8-afb9-6c7951d34d3c date time is undefined
[Microservices:MetadataService] Asset 9b7f0e5a-06cd-4cf8-afb9-6c7951d34d3c has no valid date (undefined), falling back to asset.fileCreatedAt

The JSON returned by exiftool vendored (mediaTags and then exifTags) contains:

  "SubSecCreateDate": "2020:02:10 20:24:43.45+13:00",
  "SubSecDateTimeOriginal": "2020:02:10 20:24:43+13:00",
  "SubSecModifyDate": "2024:10:03 08:15:25.45+13:00",
  "CreateDate": "2020:02:10 20:24:43.45+13:00",
  "DateTimeOriginal": "2020:02:10 20:24:43+13:00",
  "ModifyDate": "2024:10:03 08:15:25.45+13:00",

[gwensg35]

Thanks for your quick investigation.
What is the plan? any turnaround or should I wait for a patch?

[C-Otto]

I alerted the others, we might release a new version that downgrades the library.

[gwensg35]

Ok, I will wait for the new version. thanks a lot for yours efforts, this is a great tool!

[alextran1502]

@C-Otto If you want to open a PR, we can merge it in and release a hotfixes

[C-Otto]

@gwensg35 I'm pretty sure this only happens for photos taken with an offset of +13:00 (NZ summer). As this is a rather minor edge case, I suggest we wait for a fix in the upstream library and pull this in with an upcoming release of Immich. This might take a couple of days/weeks, though. Is that OK?

[C-Otto]

I have noticed same behavior with much more other files

Are all of them in +13:00 (i.e. NZ summer)?

[gwensg35]

@gwensg35 I'm pretty sure this only happens for photos taken with an offset of +13:00 (NZ summer). As this is a rather minor edge case, I suggest we wait for a fix in the upstream library and pull this in with an upcoming release of Immich. This might take a couple of days/weeks, though. Is that OK?

Sure, no problem. Thanks a lot

[gwensg35]

I have noticed same behavior with much more other files

Are all of them in +13:00 (i.e. NZ summer)?

Yes

[C-Otto]

We can fix this with exiftool-vendored v28.3.1:
https://github.com/photostructure/exiftool-vendored.js/releases/tag/v28.3.1

[C-Otto]

I tested this with v28.3.1 and I'll provide a PR for this soon. However, the asset contains the proprietary Nikon tag TimeZone (as part of WorldTime) with a value of +12:00. As such, the asset time is shown as 19:24 local time, instead of the correct 20:24. I believe the WorldTime tag DaylightSavings (which is set for this asset) must be used to fix the +12:00 to +13:00. @gwensg35 can you also provide an example image (anywhere on the world) that is not taken with DaylightSavings (i.e. in winter)?

[gwensg35]

I tested this with v28.3.1 and I'll provide a PR for this soon. However, the asset contains the proprietary Nikon tag TimeZone (as part of WorldTime) with a value of +12:00. As such, the asset time is shown as 19:24 local time, instead of the correct 20:24. I believe the WorldTime tag DaylightSavings (which is set for this asset) must be used to fix the +12:00 to +13:00. @gwensg35 can you also provide an example image (anywhere on the world) that is not taken with DaylightSavings (i.e. in winter)?

Is this one ok?

[C-Otto]

Yes! Could you provide the correct local time (and offset, if you know it)? I believe it's 31 Jan 2020 19:39 in +08:00.

[gwensg35]

Yes, correct.