Photos placed wrong on the timeline

[Roadrunner67]

The bug

I have an image in my external library

taken on April 2nd 2014, but it is placed in the timeline on July 1st 2022.
Here is the output of exiftool:

exiftool -S '.\2014-04-02 Beijing 001.JPG'
ExifToolVersion: 12.81
FileName: 2014-04-02 Beijing 001.JPG
Directory: .
FileSize: 5.0 MB
FileModifyDate: 2022:07:01 16:54:03+02:00
FileAccessDate: 2024:03:29 21:38:13+01:00
FileCreateDate: 2023:08:13 15:03:03+02:00
FilePermissions: -rw-rw-rw-
FileType: JPEG
FileTypeExtension: jpg
MIMEType: image/jpeg
ExifByteOrder: Little-endian (Intel, II)
Make: Panasonic
Model: DMC-TZ10
Orientation: Horizontal (normal)
XResolution: 180
YResolution: 180
ResolutionUnit: inches
Software: Ver.1.2
ModifyDate: 2014:04:02 12:56:32
YCbCrPositioning: Co-sited
ExposureTime: 1/30
FNumber: 3.3
ExposureProgram: Program AE
ISO: 320
ExifVersion: 0221
DateTimeOriginal: 2014:04:02 12:56:32
CreateDate: 2014:04:02 12:56:32
ComponentsConfiguration: Y, Cb, Cr, -
CompressedBitsPerPixel: 4
ExposureCompensation: 0
MaxApertureValue: 3.3
MeteringMode: Multi-segment
LightSource: Flash
Flash: On, Fired
FocalLength: 4.1 mm
ImageQuality: High
FirmwareVersion: 0.1.2.0
WhiteBalance: Auto
FocusMode: Auto
AFAreaMode: Unknown (0 11)
ImageStabilization: On, Mode 2
MacroMode: Off
ShootingMode: Program
Audio: No
DataDump: (Binary data 8200 bytes, use -b option to extract)
WhiteBalanceBias: 0
FlashBias: 0
InternalSerialNumber: (F54) 2010:02:16 no. 0448
PanasonicExifVersion: 0300
VideoFrameRate: n/a
ColorEffect: Off
TimeSincePowerOn: 00:00:23.59
BurstMode: Off
SequenceNumber: 0
ContrastMode: Normal
NoiseReduction: Standard
SelfTimer: Off
Rotation: Horizontal (normal)
AFAssistLamp: Enabled but Not Used
ColorMode: Normal
OpticalZoomMode: Standard
ConversionLens: Off
TravelDay: 2
BatteryLevel: Full
WorldTimeLocation: Destination
ProgramISO: n/a
AdvancedSceneType: 1
FacesDetected: 0
LongExposureNoiseReduction: Unknown (0)
AFPointPosition: 0.5 0.5
NumFacePositions: 0
IntelligentExposure: Off
FacesRecognized: 0
FlashWarning: No
Title:
BabyName:
Location: BEIJING
Country: DENMARK
State: SYDDANMARK
City: S├ÿNDERBORG
Landmark: ---
IntelligentResolution: Off
MakerNoteVersion: 0133
SceneMode: Off
HighlightWarning: Yes
DarkFocusEnvironment: No
WBRedLevel: 1854
WBGreenLevel: 1054
WBBlueLevel: 1815
TextStamp: Off
BabyAge: (not set)
Transform: Off
FlashpixVersion: 0100
ColorSpace: sRGB
ExifImageWidth: 4000
ExifImageHeight: 3000
InteropIndex: R98 - DCF basic file (sRGB)
InteropVersion: 0100
SensingMethod: One-chip color area
FileSource: Digital Camera
SceneType: Directly photographed
CustomRendered: Normal
ExposureMode: Auto
DigitalZoomRatio: 0
FocalLengthIn35mmFormat: 25 mm
SceneCaptureType: Standard
GainControl: High gain up
Contrast: Normal
Saturation: Normal
Sharpness: Normal
GPSVersionID: 2.2.0.0
GPSLatitudeRef: North
GPSLongitudeRef: East
GPSTimeStamp: 18:33:06
GPSSatellites: 3
GPSStatus: Measurement Active
GPSMeasureMode: 2-Dimensional Measurement
GPSDOP: 4.2
GPSMapDatum: WGS-84
GPSProcessingMethod: GPS
GPSDateStamp: 2014:03:28
PrintIMVersion: 0250
PanasonicTitle: BEIJING
PanasonicTitle2: BEIJING
Compression: JPEG (old-style)
ThumbnailOffset: 11776
ThumbnailLength: 7513
MPFVersion: 0100
NumberOfImages: 2
MPImageFlags: Dependent child image
MPImageFormat: JPEG
MPImageType: Large Thumbnail (full HD equivalent)
MPImageLength: 703293
MPImageStart: 4290560
DependentImage1EntryNumber: 0
DependentImage2EntryNumber: 0
ImageWidth: 4000
ImageHeight: 3000
EncodingProcess: Baseline DCT, Huffman coding
BitsPerSample: 8
ColorComponents: 3
YCbCrSubSampling: YCbCr4:2:2 (2 1)
Aperture: 3.3
BlueBalance: 1.722011
ImageSize: 4000x3000
Megapixels: 12.0
RedBalance: 1.759013
ScaleFactor35efl: 6.1
ShutterSpeed: 1/30
ThumbnailImage: (Binary data 7513 bytes, use -b option to extract)
GPSDateTime: 2014:03:28 18:33:06Z
GPSLatitude: 54 deg 54' 26.91" N
GPSLongitude: 9 deg 48' 46.21" E
PreviewImage: (Binary data 703293 bytes, use -b option to extract)
AdvancedSceneMode: Off
CircleOfConfusion: 0.005 mm
FOV: 71.5 deg
FocalLength35efl: 4.1 mm (35 mm equivalent: 25.0 mm)
GPSPosition: 54 deg 54' 26.91" N, 9 deg 48' 46.21" E
HyperfocalDistance: 1.03 m
LightValue: 6.7

The OS that Immich Server is running on

Qnap QTS 5.1.5 (20240219)

Version of Immich Server

v1.100.0

Version of Immich Mobile App

v1.99.0 build 129

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

version: '2'

#
# 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}
    command: ['start.sh', 'immich']
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
      - ${EXTERNAL_PATH}:/usr/src/app/external/Photos:ro
    env_file:
      - .env
    ports:
      - 2283:3001
    depends_on:
      - redis
      - database
    restart: always

  immich-microservices:
    container_name: immich_microservices
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/hardware-transcoding
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    command: ['start.sh', 'microservices']
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
      - ${EXTERNAL_PATH}:/usr/src/app/external/Photos:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: always

  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

  redis:
    container_name: immich_redis
    image: registry.hub.docker.com/library/redis:6.2-alpine@sha256:51d6c56749a4243096327e3fb964a48ed92254357108449cb6e23999c37773c5
    restart: always

  database:
    container_name: immich_postgres
    image: registry.hub.docker.com/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: always

volumes:
  pgdata:
  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=/share/CACHEDEV1_DATA/VirtualMachines/container-station-data/immich-app/library

# 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
DB_PASSWORD=4vka7YhNaAeeK7KCZGG0

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

REDIS_HOSTNAME=immich_redis

EXTERNAL_PATH=/share/Multimedia/Photos

Reproduction steps

This file was among the thousands of files in my external library when scanning.

Additional information

I have tried uploading the same image to my personal library, but it is disregarded, probably because it already exists in the external library.

[alextran1502]

Immich uses the following EXIF tags, order by priority to get the date value

const EXIF_DATE_TAGS: Array<keyof Tags> = [
  'SubSecDateTimeOriginal',
  'DateTimeOriginal',
  'SubSecCreateDate',
  'CreationDate',
  'CreateDate',
  'SubSecMediaCreateDate',
  'MediaCreateDate',
  'DateTimeCreated',
];

[alextran1502]

Hmm look like a bug as I see you have DateTimeOriginal as well. Do you mind sharing the file?

[Roadrunner67]

I thought I had added the file to the issue. Here it is attached. Best regards Den fre. 29. mar. 2024 kl. 22.06 skrev Alex ***@***.***>:

…

Hmm look like a bug as I see you have DateTimeOriginal as well. Do you mind sharing the file? — Reply to this email directly, view it on GitHub <#8375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFL3EQSLKI6LXKQWKHPQBKLY2XJUFAVCNFSM6AAAAABFO5LK5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXG4ZTOMBSG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Roadrunner67]

https://github.com/immich-app/immich/assets/22524482/67d91719-5c28-48e6-95ba-b7e2d0774055

[jenda69]

This might be related to my issue #7904. And I noticed just yesterday that if I on mobile open some people, there are bunch of old photos grouped e.g. in date 23.11.2022 but opening the photos and displaying their info shows their dates are in 2005, 2006, 2017... etc. It really feels like different parts of Immich use different kind of dates and that creates this mess...

[LucaTheHacker]

I have just noticed the same issue.
Seems that Immich is using FIleLastModified instead of FileTimeCreated (incorrect name for both, but it keeps the meaning) in my case.

[Roadrunner67]

@LucaTheHacker yes, in my example the only (visible) tag pointing to 2022 is FileModifyDate, which shouldn't be considered by Immich at all.

[Roadrunner67]

@alextran1502 could you deduct anything from the image?

[thebino]

Same issue here, I added multiple scanned images to an external library where I added the correct dates to exif manually and it placed them to today due to the modified date.

[alextran1502]

@Roadrunner67 can you help me zip the original file up and share on here? When I downloaded the file above, the EXIF data is not intact

[unhighghlow]

Have a similar issue. Just imported a ton of photos from an external source. The exif data contains the correct creation date, but the timeline says today (I'm using v1.103.0 though).

[alextran1502]

@highghlow can you zip the file up and throw it on here so I can use it for troubleshoot the code?

[unhighghlow]

@highghlow can you zip the file up and throw it on here so I can use it for troubleshoot the code?

It turns out only some photos in my backup had an exif date attached. The images that have a date attached are in the correct position on the timeline. It's not an issue with Immich.

[RanKKI]

I'm using iPhone

Same image, shows different date. ( it's a screenshot btw

  "DateTimeOriginal": "2024:06:28 14:27:11",
  "FileModifyDate": "2024:06:28 14:27:11+10:00",

But, if it's a photo, it has SubSecDateTimeOriginal with timezone info

  "SubSecDateTimeOriginal": "2024:06:28 21:22:42.299+10:00",

[rlichtenwalter]

I'm not sure if it's related or not, but while my photos end up in the right days based (or at least I haven't noticed errors at this level of timestamp granularity) on their DateTimeOriginal EXIF data, they are not ordered correctly by time. The time displayed in the UI for the photos is all over the place as you go from one photo to the next. I can provide additional detail or screenshots if helpful.

These are all photos imported from an external library on a read-only file system taken with a Pentax K-1 DSLR.

[C-Otto]

Do the assets have different (or missing) time zone (offset) information?

[jrasm91]

If you have a question about why an image shows up in the wrong place or with the wrong information, please attach it as a zip file here and I can take a look at it.

[rlichtenwalter]

I figured out the why behind my apparent lack of ordering, but despite that I have an explanation, it's undesirable behavior.

When I'm traveling internationally, my camera, when outside, GPS tags photos. When inside, it doesn't have GPS signal and does not tag. The problem is that Immich sees the GPS tagging and adjusts the time by hours corresponding to the timezone in the tag location.

This results in "inside" pictures appearing interspersed with later or earlier "outside" pictures in nonsensical ways.

Can anybody propose I way to address this? Is the problem clear? I looked for a setting to turn off Immich's interpretation of time relative to location, but I couldn't find anything.

[C-Otto]

One "half" of your photos lack time zone offset information, and thus the time zone offset defined for your server is used/assumed (which might be wrong). I don't think Immich can work around missing data, so one approach is to manually fix the time information (adding time zone offsets), or tweaking your camera/phone to add this information in all situations (indoors/outdoors).

[jenda69]

Well, it's back...
I fixed EXIFs / file modification times in my external library (details in comments of #7904) but it seems some files were not fixed or their creation/modification time got changed again when using some 3rd party tool and my timeline is wrong in some places once again.

Quite obvious here for an example, where there are photos in the dark in the middle of the day:

I played with the DB a little.

If I go to database and select assets using this:
SELECT * FROM assets WHERE "localDateTime" between '2021-01-09' and '2021-01-10' ORDER BY "fileModifiedAt" DESC
I get the same order.
If I order using localDateTime I get the correct order.

I don't understand why photos in the timeline are ordered using file modification time...

[C-Otto]

localDateTime does not have any time zone offset information, but fileCreatedAt (which should be identical to exif.dateTimeOriginal) does have this information - which is why it is used to sort photos (inside the date "bucket"). I don't think fileModifiedAt is used here.

[mehmooda]

fileCreationDate (which should be identical to exif.dateTimeOriginal)

This isn't true. Depending on how the image backups were created

#7904 (comment)

[C-Otto]

It is true:

immich/server/src/services/metadata.service.ts

Line 223 in 9871a04

fileCreatedAt: exifData.dateTimeOriginal ?? undefined,

[jenda69]

Well, I just ran metadata extraction for the whole Immich and it fixed the issue. I guess something got changed in reading and storing dates of images since I ran the extraction last time six months ago.

[C-Otto]

There was a bug, where metadata information for assets that were offline (and then online again) was overwritten.

[jenda69]

I almost got mad the bug has returned. But it didn't. Photos on the timeline are ordered correctly for me (on v1.126.1) since I re-run metadata extraction few weeks ago, but photos in todays memories are shuffled for a change. :-)