fix(mobile): sync issue due to time mismatch

[fyfrey]

Currently, the app can get sync issues because of a time mismatch between server and client. This can both occur due to timezone changes or simply wrong clocks.

With this PR, the client retrieves the time for the next sync request from the server, thus solving the issue.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
immich	⬜️ Ignored (Inspect)	Visit Preview		Oct 26, 2023 4:37pm

[fyfrey]

Idk if this solves the problem either. The issue is the database may be in a different timezone than the server still. Really we should just send accurate timestamps with timezones

dates between app/server are now always in UTC; the server and datebase use timestampz which has timezones.. so it should be good?

[jrasm91]

Idk if this solves the problem either. The issue is the database may be in a different timezone than the server still. Really we should just send accurate timestamps with timezones

dates between app/server are now always in UTC; the server and datebase use timestampz which has timezones.. so it should be good?

When we serialize a date and send it over json we're already using the ISO 8601 which is a timezone aware representation of the date and time. If this was passed along correctly to the database everything would be fine, so something is obviously not working correctly. My suspicion is TypeORM is adjusting the time, since JS Dates are only internally stored as numbers and have no sense of timezones. I believe it is offsetting it (incorrectly) to UTC.

https://github.com/typeorm/typeorm/blob/master/src/util/DateUtils.ts#L45-L80.

[fyfrey]

When we serialize a date and send it over json we're already using the ISO 8601 which is a timezone aware representation of the date and time. If this was passed along correctly to the database everything would be fine, so something is obviously not working correctly. My suspicion is TypeORM is adjusting the time, since JS Dates are only internally stored as numbers and have no sense of timezones. I believe it is offsetting it (incorrectly) to UTC.

https://github.com/typeorm/typeorm/blob/master/src/util/DateUtils.ts#L45-L80.

I see, typeORM doing random stuff again. It could also use SystemTime instead of UTC (which might be different on the systems....) I guess this would affect quite a lot of (our) code. Not sure how to fix this. Needs another PR

[jrasm91]

A bigger change I am thinking about is switching to luxon date objects, to which you can do with custom type parsers. I wonder if we left it as a raw string if that would fix this endpoint at least.

[fyfrey]

We mount /etc/localtime:/etc/localtime:ro for server and microservices, but not for the database container. Maybe this leads to issues? Because I've never encountered any sync errors.. but I also run the postgres database on the host (thus it has the same /etc/localtime)

[jrasm91]

Right if local time is the same it is never an issue. It should not be a requirement that the client, server, and database are on the same timezone though. I'm guessing this can be reproduced by having the client and server on different timezones.

[alextran1502]

Hi Fynn, do you think we still need this PR?

[fyfrey]

Yeah, it's still an issue. I'll rebase and make some changes.

[fyfrey]

rebased and made sure the app always uses the server time when possible

So, this PR guards against sync issues originating from time divergence between client and server, e.g. due clock resets or timezone changes

[cloudflare-workers-and-pages[bot]]

Deploying with    Cloudflare Pages

Latest commit:	d8413ea
Status:	✅  Deploy successful!
Preview URL:	https://668752b9.immich.pages.dev
Branch Preview URL:	https://dev-fix-sync-time-mismatch.immich.pages.dev

View logs

[jrasm91]

Superseded by #9100 and others