This project is archived and is in readonly mode.
6.days.from_now.to_s(:db) forces utc
-
Geoff BuesingIn your environment.rb, are you setting config.time_zone? This setting currently only works when your database stores UTC times -- if you want to store in local time, you have to remove this config setting from environment.rb.
Ideally, I'd like config.time_zone to work with non-UTC persistence -- still need to figure out the best way to accomplish this. See https://rails.lighthouseapp.com/... for a related discussion.
-
Steve St. Martin- Assigned user set to Ryan Bigg
config.time_zone will not effect this as its being formatted for output to the DB, which is always UTC. should be marked as wontfix as it is not a bug and can likely be worked around easily using Time::DATE_FORMATS
-
-
huberto- Importance changed from to
i was running into the same issue as ekolve and figured out what was going on. i had my Time.zone set to pacific but anytime i ran something like 5.minutes.from_now it would give me a utc time back. the to_s(:db) format doesn't have any impact.
what is going on is that from_now takes an argument but it defaults to Time.current, which does not consider the time zone, it just returns utc. Time.now, however, does respect the Time.zone setting. The confusing part is that since and from_now are aliases but you normally write the following.
5.minutes.from_now
or
5.minutes.since(Time.now)
These will actually give you different results if you're outside UTC. Seems to me all these methods should be respecting time zones by using Time.now as the default arg.
-h
-
jamiegaskins
Time.now is a standard Ruby Time object and Time.current is an ActiveSupport::TimeWithZone.
If you're using Time.current everywhere in your code, all time zones in your application will match and be adjusted by config.time_zone. However, if you use a combination of Time.now and Time.current (including methods that rely on Time.current), consistency will be compromised.
-
Santiago Pastorino
- State changed from new to open
This issue has been automatically marked as stale because it has not been commented on for at least three months.
The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.
Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.
-
Santiago Pastorino
- State changed from open to stale
-
Kevin KohrtA solution I have seen used to sychronize Time.now and Rails ActiveSupport is to use the TZ environment variable, e.g.
ENV['TZ'] = 'UTC'This may require the TZInfo gem, though. I have not tested without it, so if it does not seem to be working, try adding that gem into the mix. This is for Rails 2.3.x apps, rather than 3.x apps (for which I do not have an environment set up to test with, sadly).