Determining the current system timezone

of a client? or the server? (btw imho your server should always run in utc)

The local system where the elixir app is currently being run, so "server’ I guess.

Agreed but I can’t make that assumption.

app logic can/should be in a way that the server timezone is irrelevant.. aka always Start with DateTime.utc_now() or similar in the logic and go from there..

anyways, maybe something like

iex(20)> :calendar.time_difference(:calendar.universal_time, :calendar.local_time  )
{0, {2, 0, 0}}

(I’m utc+2 currently)

pretty sure elixir doesn’t expose it.. since it’s a very bad path to venture down of.. time is hard enough as it is..

Thanks for the help, that works nicely for the offset.

I understand the difficulties inherent in timezones in some applications. For the purposes of my app I still need to know the current timezone and offset of the system.

As a workaround you could call System.cmd("date", ["+%Z"]) or compare the output of System.cmd("date", ["+%H:%M:%S"]) with DateTime.utc_now() but that does not seem very reliable.

Why not just use the function in the Stackoverflow article

def get_timezone() do
  {zone, result} = System.cmd("date", ["+%Z"])
  if result == 0, do: String.trim(zone)
end

If you compare it with DateTime.utc_now() you would need to get the offset.

Well it seems that I read the topic not from the beginning. I completely overlooked the first post, sorry.

That being said, "+%Z" gives "CEST" on my machine, that is not very useful as it still requires to have a timezone database of some sort. And if you have one, I bet there is a function in the library that would give you your current timezone anyway.

Right didn’t realize he needed the offset. The only thing that comes to mind is Tzdata database. Elixir School has a nice article on how to use it. The only problem with this approach is you have to pass in the name of the zone, i.e. “America/Chicago”.

If there was some kind of way you could use System.cmd("date", ["+%Z"] to get the time zone and pass that in I think it would work.

The host OS, and packages available are going to determine what TZ info you can get from the system directly. For example, on Debian you can cat /etc/timezone and get Europe/London but it’s not guaranteed that the timezone packages will be installed on the host.

If you don’t control the host (and packages installed) then realistically you’re only going to be able to resolve the offset, not the named TZ e.g. “Etc/0” not “Europe/London” because there are more named TZ aliases in an offset, meaning it’s not a 1-1 relationship.

Use Timex’s Timezone.local()?