Skip to content

fix: timestamp handling for database backup in Web UI#27359

Open
AfonsoMendoncaRibeiro wants to merge 1 commit intoimmich-app:mainfrom
AfonsoMendoncaRibeiro:database-backup-consistent-time-handling
Open

fix: timestamp handling for database backup in Web UI#27359
AfonsoMendoncaRibeiro wants to merge 1 commit intoimmich-app:mainfrom
AfonsoMendoncaRibeiro:database-backup-consistent-time-handling

Conversation

@AfonsoMendoncaRibeiro
Copy link
Copy Markdown

Description

Backup timestamps embedded in filenames are server-local times, but the Web UI previously parsed them as UTC, causing incorrect relative times for users in different timezones.
The changes in this PR add an optional 'timezone' field to 'DatabaseBackupDto' and populate it from the server timezone when listing backups.
On the frontend, backup timestamps are now parsed using the server timezone and then converted to the user's local timezone before rendering relative time.
This keeps API compatibility (since it is an optional field) while fixing relative-time display across timezones.
I also included UI test coverage for non-UTC timezone parsing and user-local relative rendering.

Fixes #26502

How Has This Been Tested?

  1. Added a focused unit test for the maintenance backup entry component to verify timezone handling.
  2. The test validates that backup timestamps are parsed using the server timezone and then rendered as relative time in the user local timezone, instead of assuming UTC.
  3. Test case covers the regression scenario where parsing as UTC produced incorrect relative times.

Reproduction steps:

  1. From repository root, run:
    pnpm --filter immich-web test -- src/lib/components/maintenance/MaintenanceBackupEntry.spec.ts
  2. Confirm the test named "renders relative backup time using the user timezone instead of UTC" passes.

Screenshots (if appropriate)

Checklist:

  • I have carefully read CONTRIBUTING.md
  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation if applicable
  • I have no unrelated changes in the PR.
  • I have confirmed that any new dependencies are strictly necessary.
  • I have written tests for new code (if applicable)
  • I have followed naming conventions/patterns in the surrounding code
  • All code in src/services/ uses repositories implementations for database calls, filesystem operations, etc.
  • All code in src/repositories/ is pretty basic/simple and does not have any immich specific logic (that belongs in src/services/)

Please describe to which degree, if any, an LLM was used in creating this pull request.

I used an LLM only for initial project understanding and navigation guidance (Immich overview, codebase orientation, and Svelte/TypeScript concepts). The implementation and final changes were done by me.

...

…eb UI

Frontend parsed backup timestamps as UTC, but they were in the
server's local timezone, causing wrong relative times.

Add `timezone` field to DatabaseBackupDto to expose server timezone.
Update frontend to parse timestamps using this timezone.
Convert timestamps to user's local timezone before rendering.
Fallback to browser timezone if server timezone is missing.

Ensures correct relative time display in Web UI.
@immich-push-o-matic
Copy link
Copy Markdown

immich-push-o-matic bot commented Mar 28, 2026

Label error. Requires exactly 1 of: changelog:.*. Found: 🖥️web, 🗄️server. A maintainer will add the required label.

@bwees bwees changed the title Fix #26502: Fix timestamp handling for database backup in Web UI fix: timestamp handling for database backup in Web UI Mar 28, 2026
@@ -283,6 +281,7 @@ export class DatabaseBackupService {
async listBackups(): Promise<DatabaseBackupListResponseDto> {
const backupsFolder = StorageCore.getBaseFolder(StorageFolder.Backups);
const files = await this.storageRepository.readdir(backupsFolder);
const timezone = DateTime.local().zoneName;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this will get the timezone set from the TZ variable?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, your assumption is correct.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can also add a short comment in the code if you'd like, to make that behavior clearer.

@@ -16,6 +16,8 @@
expectedVersion: string;
};

type BackupWithTimezone = DatabaseBackupDto & { timezone?: string };
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need a custom type here? Can you run make open-api to generate the correct type from your changes on the server?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Inconsistent timestamp handling for database backups in Web UI (relative time incorrect)

2 participants