-
Notifications
You must be signed in to change notification settings - Fork 21.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time is created in UTC with local time #3145
Comments
What rails version are you using? |
I have tried from rails 3.0.7 til 3.0.10. all the same bug. |
This also happened with me when using Rails 3.1.0. |
Can a time be timezone aware without a date? What about daylight savings handling? For example a local time in Europe/London today is one hour ahead of UTC but in a month’s time it will be equivalent to UTC. |
Pixeltrix, that's why Time in ruby as a date. Have you understood my problem? |
The problem with treating a time column as timezone aware is that the conversion to local time will be different depending on what day of the year you access it. For example if I save a local time in Europe/London today it will take a hour off when saving it to the database in UTC format. When I come to read that time in a month then the local time generated from the UTC time in the database will be different to the one that was saved. |
@thiagodiniz Is this still a problem in Rails 3.2.x? (@jeremyf) |
After investigating this I'm leaning towards closing this because it's pretty much an intractable problem. It turns out that time columns are all given the same date (2000-01-01 to be precise). This can cause an issue if you use Just using the current date wouldn't help as it would return a different time depending on what day of the year you read the record. One possible solution is to write time columns out as local time and not as UTC and read them in as local time. At least this way you'd end up with the same time on every day of the year. |
@jeremyf, i haven't tested yet. Thanks for the remider. @pixeltrix thanks for taking a look in this case! |
@thiagodiniz can you close the ticket? |
Don't close it just yet as I need to discuss with either @tenderlove or @jonleighton whether we should use |
For anyone stumbling across this, here's a way I created to address this in your models: https://gist.github.com/2961926 Put this in lib/. Then do this class MyModel < ActiveRecord::Base
include DstHelper
applies_dst :from => :date, :to => :time
# ...
end Now, when you access my_model.time, you'll get what you expect for the given date. |
Is this still an issue? |
@JasonBenn I think so - I'll try and take a look at it this weekend |
I tried to replicate this in a test (see PR) and it all seems to work like expected, the time is saved as utc, but correctly so... Albeit, issue #6816 is actually a better description of the unexpected behavior - the time is read as utc, and not converted to local time on the read. That might be something worth looking into. |
Bug still exists in Rails 4.0.2. |
@jsuwo I'm aware that it still exists but unfortunately it would impact on too many things this late in the release cycle so it's scheduled for fixing in 4.2. |
@pixeltrix Yep, I just wanted to mention it since I saw a number of posts asking if this was still an issue. Thanks. |
This issue has been automatically marked as stale because it has not been commented on for at least The resources of the Rails team are limited, and so we are asking for your help. If you can still reproduce this error on the Thank you for all your contributions. |
I was unable to reproduce this issue using the following gist, on any of the currently supporting branches. https://gist.github.com/sgrif/0af0158e1875387956a7. Since this issue is also marked as stale, I'm going to close this, since it appears to be resolved. If this issue still exists for you, please open a new issue. |
Apologies, I mistakenly read this as |
#15726 fixes this for 4.2. It's a significantly more difficult change to make without the refactoring work I've done in master, so I'm not sure that we can back port it to 4.1 or 4.0, but I will spend some time looking at it. (Any back port would add a configuration option to allow this behavior on 4.1, but the default would need to remain the same.) |
@sgrif, thank you for the time spent solving this issue. |
Thanks @sgrif! |
Not sure if we can do anything about Time.current. Everything will convert properly going into the database, but we lose the date (and therefore DST) info coming back out. I'll spend some time looking at this case tomorrow and see if I can at least make sure the behavior is documented. |
@pixeltrix I've updated to handle the model.attr = value
# This is not guaranteed
model.attr == value
# These are guaranteed
model.attr_before_type_cast == value
model.save
model.attr == model.reload.attr Since the date will be lost when round tripping, and we assume the date is 2000-01-01 coming out, we should make enforce that the same is true going in. |
Is there a suitable workaround for this issue? I'm seeing the behaviour that if |
@simonask That sounds like an unrelated issue, please open a bug report with a reproducible case demonstrating the behavior. |
This issue has been automatically marked as stale because it has not been commented on for at least The resources of the Rails team are limited, and so we are asking for your help. If you can still reproduce this error on the Thank you for all your contributions. |
That's not working for me. I updated to 4.2, set config.time_zone = 'Europe/Paris' but still have UTC time 2000-01-01 18:00:00 UTC |
2 years later, we have this problem (only in local/staging env but not in production..)
applications.rb have without config.active_record.default_timezone if we add config.active_record.default_timezone = :local What can we do in order to fix it for rails 3.2.14 ? (without uppgrading to rails >4.3) |
Rails 5.1.4 ApplicationController.rb
time_select ignore the timezone. |
When a Model is created using the mass assignment, and the model has a time attribute.
The Time attribute is created in local time but with UTC time zone even with config.time_zone properly setted.
I was studying this wrong behavior and guess that the error is here:
https://github.com/rails/rails/blob/master/activerecord/lib/active_record/attribute_methods/time_zone_conversion.rb#L62
As you can see, in the line 62 it only consider :datetime and :timestamp. it does not consider :time to be timezone aware.
The text was updated successfully, but these errors were encountered: