Formatting date and time in an email in the correct timezone

I’m want to send emails from my elixir/phoenix application that contains information about events stored in the database. Included in this information is the date and time of the event. The event times are stored in the DB as UTC timestamps. I also have lat/long coordinates of the event location in the DB.

Ideally in the email the event time would be formatted to be displayed in the timezone of the location where the event is being held.

e.g. if an event being held in Paris, France is at 2019-11-20T13:00:00Z this might be displayed in the email as “20 Nov 2019, 14:00 CET”.

Alternatively the time would be displayed in the recipient’s timezone. This is tricky though as I have no control over any client side date parsing etc in an email.

I’m aware of 3rd party APIs that can give a timezone from a lat/long but I’d like to avoid adding such a dependency.

I am also considering attaching an invite.ics to the email so that compatible email clients can parse it and display it in the recipient’s timezone.

Are there any good suggestions for solving this problem? I imagine it must be quite a common challenge.

1 Like

You can also do it on your own with resources like:

Just be aware that there are regions out there with overlapping timezones.

This is done automatically if the .ics does contains the correct datetime/timezone.

The best way is to ask the client if you cannot be sure the event is in the same timezone as the client is currently.

There is an Elixir library tz_world that uses the underlying data from evansiroky/timezone-boundary-builder. The current hex version relies on Ecto and PostGIS but:

Using my fork:

iex> TzWorld.timezone_at 3.25, 45.1                            
{:ok, "Europe/Paris"}

Good to know. I did build something similar on my own a few month ago.

Thanks that’s a great suggestion. I’ll give it a go

There’s also geotz based on the excellent dark sky tz-lookup library. Was built and used for a platform in production a while back, where we had to fetch many timezones dynamically.

Edit: It hasn’t been released on hex, we just used the github source.