Displaying UTC DateTime in users browser TimeZone

Unfortunately the first approach will not work, since browsers do not usually send information about their computer’s configured timezone to the server.
This pretty much leaves the second approach as the only possibility.

I believe that there exist many drop-in libraries that allow you to display datetimestamps in a particular timezone in pure browser-friendly JS.
I’ve used moment.js before myself in the past, but it is by no means the only option out there.

BCP47 defines a U extension to the language identifier that is defined in CLDR and is used in the HTTP Accept-Language header. So if the user selects an appropriate language identifier, the requested time zone can be transmitted. As an example en-AU-u-tz-ausyd-ms-metric-fw-mon means “english as spoken in Australia with time zone for Sydney, measurement system metric and the first day of the week is Monday”.

Whilst totally supported in the standard its fair to say that its not an extension often used and probably unreasonable to ask a browser user to do it this way. Totally reasonable to ask an API client to do it though.

My approach relies on the Timex library and the ECMAScript Internationalization API:

When a request comes in, I check get_session(conn, “tmzn”). If tmzn is not yet part of my session, I add data-tmzn=“1” to my document head. JS then checks document.head.dataset.tmzn on DOMContentLoaded and, if it returns a value, it sends an async GET request to:

“/timezone?iana=” + encodeURIComponent(Intl.DateTimeFormat().resolvedOptions().timeZone)

Once the server receives this, the timezone can be added to the session, following its verification by calling Enum.member?(Timex.timezones(), iana). From that point onwards, all dates can be rendered server-side with the help of Timex.

This approach may or may not fit your use case, the most obvious issue being that it does not work (at least not out of the box) for the initial page shown to the user.

Thanks!

That was very valuable information! For now, I hacked JQuery+moment solution solution:

let convert_dates = function() {
  $(".utc_to_local").text(function(index, utc_date) {
    return moment.utc(utc_date).local().format('YYYY-DD-MM HH:mm:ss');
  });
};

# for live views
$(document).on("phx:update", convert_dates);
# for regular views
$(document).ready(convert_dates);

But I think I’ll change it later. When I have signing in, I’d like to get timezone from browser via login form and then save it in session. This way, I can format dates server side which won’t require two additional JS libs.

I’d just like to note that if you’re dealing with timezones then you may be dealing with different cultures and languages. Which also means that the users expectation of date/time format may also be different..

Have you put this sort of functionality into a plug? This sounds incredibly useful!

Unless the browser sends the user’s timezone in a header or something, the backend has no way of knowing what the user’s timezone is.

I am no expert, but this appeared to generate my timezone when I tried calling it in browser console.

Intl.DateTimeFormat().resolvedOptions().timeZone # returned “America/Denver”

I am no expert on the API here, but it appeared to work when I tried it.

Right, that’s the browser. But the issue is, plug doesn’t run code in the browser, plug runs code on the server, so unless the browser sends that information to the server in the HTTP request, plug can’t do anything about it.

Yeah in @konstantine’s reply he built an endpoint to send that data on DOMContentLoaded to the backend.

When a request comes in, I check get_session(conn, “tmzn”). If tmzn is not yet part of my session, I add data-tmzn=“1” to my document head. JS then checks document.head.dataset.tmzn on DOMContentLoaded and, if it returns a value, it sends an async GET request to:
“/timezone?iana=” + encodeURIComponent(Intl.DateTimeFormat().resolvedOptions().timeZone)