Skip to content

Immich Web App titling recent days "last month" #11504

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 of 3 tasks
williamkray opened this issue Aug 1, 2024 · 3 comments · Fixed by #11506
Closed
1 of 3 tasks

Immich Web App titling recent days "last month" #11504

williamkray opened this issue Aug 1, 2024 · 3 comments · Fixed by #11506

Comments

@williamkray
Copy link

williamkray commented Aug 1, 2024

The bug

today is July 31st. current time is 7:07PM PDT.

In my timeline on the web app, I have pictures from July 31st, and July 30th (as well as before then).

Instead of dating the pictures from today as "Today", the header is "Last Month". Same for the pictures from July 30th, instead of "Yesterday" it titles them "Last Month".

Selecting the radio button next to either of these "Last Month" titles selects BOTH title radio buttons, but only appears to select the pictures from the day of the originally selected radio button.

Adding the TZ env var to my docker deployment does not impact the titling.

This behavior was not noticed on the previous version of the server. Mobile apps correctly title the pictures from "Today" as "Wed, July 31".

image

The OS that Immich Server is running on

Docker Compose

Version of Immich Server

v1.111.0

Version of Immich Mobile App

v1.111.0

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

immich:
    image: ghcr.io/immich-app/immich-server:release
    restart: always
    volumes:
      - ./storage/immich/media:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
      - ./storage/photoprism/photolibrary:/legacy:ro # photoprism library
    expose:
      - 3001
    environment:
      DB_PASSWORD: REDACTED
      DB_USERNAME: REDACTED
      DB_DATABASE_NAME: REDACTED
      TZ: America/Los_Angeles
    depends_on:
      - immich-redis
      - immich-psql
    networks:
      - traefik
      - immichdb
    labels:
      - "traefik.enable=true"
      - "traefik.docker.network=traefik"
      - "traefik.http.routers.immich.entrypoints=websecure"
      - "traefik.http.routers.immich.tls.certresolver=le"
      - "traefik.http.routers.immich.rule=Host(`immich.my.host`)"

Your .env content

env variables are added to my service definitions in my docker compose file

Reproduction steps

1. run immich in docker containers
2. have pictures from the last few days
3. visit the page on July 31st (not sure if this is relevant but it feels important)

Relevant log output

no relevant log data from the server is generated.

Additional information

No response

@williamkray
Copy link
Author

just realized i have two ways of setting timezone... mounting localtime as a volume and i've now added the TZ env var. i've removed the mounted localtime file to see if that resolves it, but it does not appear to have any impact.

@lf-
Copy link

lf- commented Oct 1, 2024

Hmm, I don't think this was correct to close. I have an Immich 1.115 running on a server which is in UTC (because it's a server), and it's nonetheless doing this exact thing to recent images, in spite of #11506 being in 1.112. I am suspicious of this being a case of it being late in the month (and my immich server (UTC) being in a different month than the client (UTC-8)) and there being buggy date code exposed by that fact.

I would hope that the server timezone does not matter to this, since it would prevent people across multiple timezones using an Immich instance. The somewhat cursed fact here is that the date that should be used for the purposes of rendering is the date in the photos' own timezone, which avoids tearing dates if you are on vacation far away and cross the date boundary of your server or later client.

I was reminded of this bug, but I don't think it's the cause here (since immich uses luxon which surely isn't itself broken) github/relative-time-element#285

@eugeniumegherea
Copy link

hey, I think this exact issue happened to me

Image
my timezone is GMT+2 so its 1st of March here while photos were taken "yesterday" on feb28 midday
release 1.128.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants