Here’s one approach to letting users select a locale like “America/New_York”:

  def locale_list do
    now = DateTime.utc_now()

    Tzdata.zone_list()
    |> Enum.map(fn zone ->
      tzinfo = Timex.Timezone.get(zone, now)
      offset = Timex.TimezoneInfo.format_offset(tzinfo) # added in v3.78
      label = "#{tzinfo.full_name} - #{tzinfo.abbreviation} (#{offset})"

      {tzinfo.full_name, label}
    end)
    |> Enum.uniq()
  end

This outputs a list of values like:

[
  {"Africa/Abidjan", "Africa/Abidjan - GMT (+00:00:00)"},
  ...
]

If you wanted to sort these by offset, you could use the value of Timex.Timezone.total_offset(tzinfo), but I think alphabetical makes more sense, since the locales are grouped by region.

In the template, I think an <input> with a <datalist> is better than a <select>, as it lets users type and use autocomplete, which in my testing will match any substring, like “africa” or “abidjan” or “gmt” or “05:30” (although exactly how that works is up to the browser). This means that if somebody knows their offset and wants to type it, it can narrow to the locales that match.

<input list="locales" name="user-locale" id="user-locale" value={@user.tz_locale}>
<datalist id="locales">
  <%= for {fullname, label} <- @locales do %>
    <option value={ fullname } >
      <%= label %>
    </option>
  <% end %>
</datalist>

It’s still not as nice as being able to type the name of whatever town you live in, big or small, but the answers above could help you do that.

Oh yeah, and Intl.DateTimeFormat().resolvedOptions().timeZone in JS can get the user’s locale from the browser - "DateTimeFormat" | Can I use... Support tables for HTML5, CSS3, etc

So you can add a button to autofill:

<button phx-hook="AutofillLocale">Autofill</button>

…and set up a hook to do it:

Hooks.AutofillLocale = {
  mounted() {
    this.el.addEventListener("click", e => {
      let locale = Intl.DateTimeFormat().resolvedOptions().timeZone
      document.getElementById("user-locale").value = locale
    })
  }
}

Here’s a quick demo:

I don’t see a straight forward way, but I’m also not convinced its a good idea (including as a consumer). Why? With DST the UTC offset changes. Are you displaying the standard offset or the summer offset? If I select “Australia/Sydney” am I actually selecting the offset of UTC +11:00 or the zone Australia/Sydney.

I appreciate this may not be the interpretation of everyone. But in my opinion, use the zone name only. And to simplify, as a user, I would prefer to use the data from Tzdata.zone_lists_grouped/0 and group the data by region.

This speaks in part to the whole challenge off “who you are, where you are from, where you are now, what preference you choose…”

An example: I’m a Hertz customer. My profile is clear, my address is Singapore, my nationality is Australian. But whenever I am in Germany I get the German translation for Hertz. They must be using IP address detection - but thats the lowest of the low. They have the tracking cookie for me - why do they do that!!!

For a registered user, follow their preferences. For a user that provides an Accepts-Language header use the -u-tz-zone if provided. Do everything you can to empower the user to define what they want.

But for goodness sake, assuming that a typical consumer knows that UTC means let alone UTC + 11:00 is a really poor and I might say lazy experience. I appreciate this is the common strategy. But even as an informed consumer I find it confusing.

I believe (and recognise this may not be the common view) that there are already two good UX choices:

1. Use the “You prefer the times you see on this site be the time in _________ (some location)” or
2. “Please select the current time that best reflects your preference: -________”

PS: This is a rant about the current state of UX in general, not about the original posters question or intent.

There are timezones like Florida, which are all year in DST, effectively never experiencing their actual UTC offset. The whole EU is currently on the way to scrap DST switching leaving member states to decide if they want to stay on DST or non-DST.

That’s interesting. I can’t remember ever choosing my timezone by UTC offset. It’s always been timezone names where I had to do so.

If you follow the approach of “offset + timezone name” then as a user I would prefer “Australia/Sydney (currently UTC +11:00)”.

I don’t actually believe most users understand time zones, offset, DST and so on. My personal view is that you would say something like:

The current time for you is __________

And the drop down shows the time in different zones that I can select. And then interpret the zone name from that.

In my view using offsets and zone names is, for the average consumer, making technology their problem.