I'd like to not store times in my local timezone, but Sequel is making it really tough on me. I can set them to UTC before I put them in there (a bit of a pain), but then when I take them back out it assumes that they are local dates and then they are all 8 hours in the future. Is this something that hasn't been implemented yet? And if so, are there any workarounds? Thanks!
相关问题
- How to specify memcache server to Rack::Session::M
- Why am I getting a “C compiler cannot create execu
- reference to a method?
- ruby 1.9 wrong file encoding on windows
- gem cleanup shows error: Unable to uninstall bundl
相关文章
- Ruby using wrong version of openssl
- Difference between Thread#run and Thread#wakeup?
- how to call a active record named scope with a str
- “No explicit conversion of Symbol into String” for
- Segmentation fault with ruby 2.0.0p247 leading to
- How to detect if an element exists in Watir
- uninitialized constant Mysql2::Client::SECURE_CONN
- ruby - simplify string multiply concatenation
Just had a very similar issue myself.
This information has been taken from the Sequel RDoc
Also make sure your not storing the timezone information in your database. I'm using Postgres and the column type is timestamp without time zone.
This should result in the displayed Date/Time being in UTC. It has worked for me when passing in a Date/Time of 2009-07-13T03:22:53Z the result is displayed as 2009-07-13T03:22:53+00:00
The easiest way to try to put them in as UTC is to override literal_datetime and/or literal_time for the dataset class you are using to return a literal string of the UTC time.
Getting them out in UTC depends on the adapter you are using. For example, the postgres adapter calls Sequel.string_to_datetime, which just calls parse on the Sequel.datetime_class (Time by default). If the datetime column includes the timezone information, things should work fine. If it doesn't include timezone information, Time.parse is going to assume it is given a local time. In that case, you may want to override Sequel.string_to_datetime to make sure it always returns the time with the UTC offset (maybe by calling Time.parse(s).gmtime).
This is a bit outdated at this point but I believe the best solution here has changed since the original answer was posted. If you set
sequel will treat all times as UTC and wont exhibit the behavior described in the question.
Find more info at http://sequel.jeremyevans.net/rdoc/classes/Sequel/Timezones.html