LuchoTurtle
commented
1 year ago To tackle this, I thought it would make sense to preserve the UTC in the server and only show the user the date time according to the browser’s timezone. This entails that whenever a user updates a timer, the UTC equivalent is saved in the database. So between the client and the server (inbound and outbound), there must be a conversion from UTC to the local timezone.
This local timezone depends on the browser and thus will eventually be sent to the liveview from the client.
First strategy
Initially, to do this, I checked a few resources:
- https://elixirforum.com/t/display-datetime-in-users-timezone/45732/8
- https://elixirforum.com/t/why-use-utc-datetime-over-naive-datetime-for-ecto/32532/19
- https://elixirforum.com/t/displaying-utc-datetime-in-users-browser-timezone/2836
- https://hexdocs.pm/phoenix_live_view/js-interop.html
I realised I could use a mix of on_mount on the LiveView and create a hook that would be called with on_mount.
Inside this hook, we can use attach_hook to try and assign this local timezone to the socket assigns list.
However, after trying several times to get this to work and pushing events from app.js, I realised that this operation of assigning the local_timezone to the socket assigns from the client was not made exactly on mount. There would be a split second where the component would be re-mounted with the socket assigns properly set.
Although this behaviour was sufficient, I felt it was incorrect. And apparently I wasn’t alone (as shown in https://thepugautomatic.com/2020/05/persistent-session-data-via-localstorage-in-phoenix-liveview/).
Second strategy
So after spending unnecessarily amount of time for this to work, I luckily stumbled upon get_connected_params/1. Wish I had found this earlier, because it was exactly what I needed.
Having scraped the previous method, I went with going for this on the on_mount function within app_live.ex by doing…
hours_offset_fromUTC: get_connect_params(socket)["hours_offset_fromUTC"] || 0…in the socket assigns. It worked fine.
Why second strategy works and what went wrong
I then tried to pass this new socket assigns hours_offset_fromUTC to the list_timers_changesets/1 inside the timer.ex so I could return the list of Timer changesets with the the updated date times (incrementing/decrementing the number of hours according to the timezone).
However, I wasn’t able change the data property inside the changeset:
- Tried to use
Enum.mapand iterate over the list and change the properties manually. This didn’t work because calling thechangeset/1function would reset the newstartandstopvalues of the timer immediately. - Tried to use
Map.put/3to override these values inside the changeset. Same thing happened. - Tried to use
Kernel.put_in/3but didn’t work either. - Tried to make changes programatically (https://elixirschool.com/en/lessons/ecto/changesets#adding-changes-programmatically-3) by using functions like
change/2or adding actions and then trying to apply them by callingapply_changes/1but this didn’t work because after applying the changes, the a Timer object was returned with the changes instead of a changeset. We need the changeset to be returned because it is used in the client-side (app_live.html.heex) to make user input validations and show correct feedback (for example, try to update a Timer with an incorrect format).
Since these weren’t working, I simply had to put some logic inside app_live.html.heex to show the user the correct date time and then change back the timezone when updating the timers.
nelsonic
codecov[bot]
closes #353
This took much longer than expected mainly because of the strategies that I tried to employ. These are detailed in the comments below.
This PR essentially adjusts the timezone for the user on the client side and maintains UTC-based datetimes on the server to maintain consistency across all timer objects. The client sends the timezone during the
mountingphase and is set as a socket assign within the LiveView.