Generally it makes sense to shift tz conversion to the edge as far as possible (view layer, if not the client itself), but making everything (just) UTC within the backend is not necessarily sufficient, see UTC is not Your Saviour – Random Notes. Depending on the usecase knowing the local time of things can be just as important as knowing the UTC version of it.

As for more practical advice. Elixir core can handle datetimes quite well today. I’d rather opt for more focused libraries rather than timex. Elixir core for the data types. For timezone database tzdata or tz. For datetime parsing (if needed) date_time_parser or datix. For datetime formatting either Calendar.strftime or ex_cldr. And for storage base ecto tools of tz_datetime if the timezone needs to be retained or future datetimes are handled.

As I’m storing future datetimes, I’m using ex_cldr, tz_datetime and tz.
To help user find the correct timezone, I’m filtering the timezone select using the country were the event will be held.

@LostKobrakai Well … You did not got me this time.

I was talking about changing support everything on backend to UTC + client timezone (one but not explicitly said)… I never suggested to use UTC for multiple timezone handling. To be precise I was talking about move unnecessary logic to client which solves said problems without extra libraries (see code example).

I never worked on “1 of 10” edge cases mentioned in linked article, so I don’t have strict opinion on it. If I would work on chart in linked article most probably I would not even work on date time.

defmodule Example do
  defstruct ~w[day_num inserted_at hour name points]a
end

“Main” fields (i.e. day_num, hour and points) are important for graph.

The rest two fields are optional. inserted_at would be an UTC date time and under name could be anything like Tokyo or <shop name> in <city name>. With this I could manually preview edge cases of reported points like “jet lag” or “climate shock” in first days in new place like select * … where inserted_at > … and name = 'Tokyo' limit 720 (hours in 30 days).

Honestly I don’t see why in this case we need to work with any timezone when it’s not important from very start, so for me it’s not even topic about UTC vs local time.

@enkr1 As you can see above, depending on use case the solution could be completely different. Please give us a bit more information and we can give more precise ideas!

Usually you see the “clock time” be called wall time.

Yeah, human language is hard. Much smarter people than me said that choosing the right word enables and empowers thinking about a problem. Sadly the reverse is even truer: choosing the wrong words cripples the potentially critical thought process about a problem.

No easy solution. Hence we all try and digest things into our own brain machine micro-code.