fix(mobile): display original creation date

[juaoose]

Description

This PR attempts to match the dates displayed on the mobile application with the web application. Currently, the web application shows the original creation date, where the mobile application shows the date adjusted to the device's locale.

Current Web	Current Mobile

With this change the dates displayed on both platforms would essentially display the same information (this PR's main focus is not to match the exact format)

How Has This Been Tested?

This was manually tested with multiple photos taken in a different time zone.

Edit: Widget tests were also added.

Screenshots (if appropriate):

Checklist:

• [x] I have performed a self-review of my own code
• [x] I have made corresponding changes to the documentation if applicable. N/A

[vercel[bot]]

Deployment failed with the following error:

Resource is limited - try again in 10 minutes (more than 100, code: "api-deployments-free-per-day").

[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		Jul 10, 2023 3:50am

[juaoose]

I don't think I have a solid idea on how to handle the "UTC+2" timezone format...

[alextran1502]

Without resolving issue with UTC+/-x, I don't think this PR can be merged because we will have instance of local time is correct but then the displayed timezone will be incorrect.

[juaoose]

Without resolving issue with UTC+/-x, I don't think this PR can be merged because we will have instance of local time is correct but then the displayed timezone will be incorrect.

I agree, I think it might be doable but it would pretty much be like: grab that local date we get from Isar, add() or substract() time based on the provided string UTC+/- and then just build the "GMT+-X" string manually.

Looks like the only way to do it with DateTime, since it only supports either the date being at the current locale or at UTC.

That solution might also fail with DST and such time intricacies... although I'm not sure we can avoid them without only using IANA codes instead of offsets.

Any ideas are welcome :)

[alextran1502]

do you have update on this pr?

[alextran1502]

Hello any news on the implementation to cover all cases?

[juaoose]

Hello any news on the implementation to cover all cases?

Sorry for the delay, I think both cases are properly handled now.

[alextran1502]

Superseded by #4774