travisf
I’m sending a daily report which should be showing the current time set to mountain daylight time. However, after daylight savings time the report has been consistently an hour behind. I if I run Timex.now("MDT") in the terminal I will get the current time in MDT. Our report is generated much the same way: {:ok, date} = Timex.format(Timex.now("MDT"), "{h12}:{m} {am}") Again, this works in my terminal but not on the report that gets sent out; it’s an hour behind.
However, if I change Timex.now("EST") I will get Eastern Time but an hour behind (right now it’s 11:15 EST but I’m getting 10:15).
Any ideas on what the cause of this might be? Is there a Phoenix config somewhere that sets time?
Trending in Questions
I’m aware of 2 such projects, are there others?
git: GitHub - team-alembic/realworld: A fullstack Phoenix LiveView application with back...
New
I having some trouble figuring out if I have set myself too strict of standards for my production server. Currently I can handle 75% of r...
New
Hi everyone.
My team and I have been working on a fairly modest app based around video streaming and chat, but we’ve landed a customer t...
New
I really like the adapter patterns that ecto, nebulex, waffle, etc. use and would love find something similar for a key management servic...
New
Hello folks!
So at work, we are seeing some situations where we have to define some “fixed” strings that are used across the codebase in...
New
How Can I Optimise Compile Time Dependencies
I have been building an elixir application for about 2 years now. Many modules and files ha...
New
Other Trending Topics
Sauron
There he took up again his great Ring in Barad-dur, and dwelt there, dark and
silent, until he wrought himself a new guise, an i...
New
A little off-topic, but I feel like people here have a good head on their shoulders.
I used to be quite good at making software. Was luc...
New
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
There has been a thread to discuss the Stack Overflow Developer Survey on this forum every year since 2018, so here’s yet another one for...
New
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
- #ai
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming











Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
dimitarvp
Maybe the production deployment server doesn’t have daylight savings enabled?
Do you have access to it? Can you test with the usual UNIX commands on the terminal?
travisf
I can test that for sure, but this happens locally too. If I send the report in a development environment it will be an hour behind.
thojanssens1
If I understand correctly, you have a different result for that instruction in your app and in your local terminal?
My approach would be to identify what is different.
I can see potentially two things when calling
Timex.now/1(never used the lib but had a quick look at its code).:os.system_time()tzdatalib.Would you be able to, once from the app and once from your local terminal, check the output of
:os.system_time()andTzdata.version()?dimitarvp
Then maybe your local and production DBs don’t have the daylight savings activated? Just shooting in the dark, it’s the first good assumption I could make.
travisf
I think I’ve realized the issue. Our code was actually using
Timex.now("MST")I thoughtMSTandMDTwere interchangeable or that Timex would account for daylight saving time. It seems likeMSTwill be incorrect about 8 months out of the year, I can’t verifyMDTseems likeAmerica/Denveris the way to go.@dimitarvp your daylight savings mention got me on this track.
thojanssens1
“MST” used as a time zone ID has a constant offset of -7 hours from UTC for the whole year. It’s not a bug. It’s a rule written in the IANA time zone database.
“America/Denver” is a time zone ID and MST/MDT are abbreviations for that time zone.
travisf
I didn’t say it’s a bug, when I said “incorrect” I just meant in the case where we had used it to display text on an email. You mention the offset for MST, is MDT then going to be -6 hours from UTC for the whole year as well?
thojanssens1
I think I confuse you more:) but the IANA tz database can be very confusing.
“MST” can be used as a time zone ID; but for example “MDT” seems not to be a valid time zone ID.
^ So this should actually throw an error
Anyway, this is not what you want. You want to use “America/Denver” as a time zone ID.
When you use “America/Denver” as a time zone ID, the offset will change throughout the year:
-07:00/MST and -06:00/MDT
travisf
It doesn’t throw an error, it just gives the current time (since we are in daylight time). But I am now using “America/Denver” as the time zone ID for much of the app. Thanks @thojanssens1.
LostKobrakai
This is actually how timezones work. Timezone names alike MDT are names for certain UTC offsets. Area names like “America/Denver” are the names, which define which of those timezones is in effect in a certain area of the world at a certain time.