silverdr
DateTime documentation contains the following sentence:
If you want to get the current time in Unix seconds, do not do
DateTime.utc_now() |> DateTime.to_unix(). Simply callSystem.os_time(:second)instead.
Nice, but… System documentation says about os_time/0 and os_time/1 as follows:
This time may be adjusted forwards or backwards in time with no limitation and is not monotonic.
Now, I DO “want to get the current time in Unix seconds” (or microseconds) but I want it to be the current time in UTC, God forbid in one of the tons of useless “time zones”, nor with / without equally useless DST changes. So the question - how is doing System.os_time(:second) supposed to be a better equivalent of doing DateTime.utc_now() |> DateTime.to_unix()? Am I missing something here?
P. S. Yes, I do run my computers (including the one I write these words on) on UTC so I believe in such case I expect those to be equivalent, right? Still more than once I had to work on servers configured… well.. differently and had to deal with code that never expected to be run “in different timezone”, so I am really curious what’s the case here
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
al2o3cr
Based on the implementation of
DateTime.utc_now/1:https://github.com/elixir-lang/elixir/blob/a64d42f5d3cb6c32752af9d3312897e8cd5bb7ec/lib/elixir/lib/calendar/datetime.ex#L93-L95
I’d guess the documentation’s suggestion is for efficiency; no point in building an intermediate
DateTimejust to turn it right back into an integer.silverdr
Thank you for your response! Yes, it makes little sense to waste cycles on converting from one representation to another only to convert it immediately back to the original one. But now this is even more confusing. As the DateTime docs say about
from_unix!/3:Which would imply that the result of
System.os_time()is “always in UTC”. How can (general relativity aside) something that is always in UTC “be adjusted forwards or backwards in time with no limitation […]” as the System docs explicitly warn about?hauleth
NTPd adjustments. Simply your machine may have invalid time set and on the next check the time will be shifted to match the result returned from the NTP server.
silverdr
Right, makes sense! Thanks.