-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
ActiveRecord time field issue with timezone #51679
Comments
I tried to help with this on discord... we couldn't get the time_zone config to stick. ENV["TZ"] and the like didn't help either. Is there an example of a single file bug repro that includes tz changes? |
I don't think the linked test matches/describes quite this behaviour -- that is showing a conversion between stored and reported time zones, which shifts the result back a few hours (ending up on the 31st). Here the actual time component is correct, but a full day back. 🤔 Oh, I think I understand. The test behaviour feels intuitively correct to me: the stored value is midnight, and then when it's loaded in an offset timezone, the value is "N hours before midnight". But here, the application is consistently working in Brasilia TZ, so it intends to store "22:00". Because the DB is using UTC, though, that ends up stored as midnight on the 2nd... truncated to 00:00 by the time field. And then when loaded, the DB said "midnight on the 1st, UTC"... which after TZ correction, is 2 hours before that, on the 31st. I think this a fundamental problem with having the application and database timezone differing while storing unanchored time values: the storable range is represented by Jan 1 in the DB zone (because that's what the DB can represent), and that's what we're trying to translate for the application. If you look at the raw values stored in the DB at the midpoint of the test, I think that will show why I don't remember how |
@PedroAugustoRamalhoDuarte if your goal is to compare Time of Day without a specific date, one option is to use the Tod gem, particularly the ActiveRecord integration. Please ignore this if your goal is to compare on specific dates. Time of Day comparison detailsExpectationWe want to work with a time of day, no date involved. This comparison should be true: end_time ProblemThe Ruby Time and ActiveSupport::TimeWithZone include date. They represent a specific point in time, not the concept of Time of Day.
As @matthewd pointed out there is also conversion into/out of Postgres type which breaks the comparison in certain times/timezones as the UTC offset gets applied and then stored. Even if you set up the column to persist as a Postgres Approach I've used
|
Thanks for the fast response!! Thanks, @mkbehbehani, for the solution's approach. I am using the third approach right now, and it's working nicely. And thanks for express my problem better. I think we can improve the rails default conversion for time field. When we work with time, even though we have to deal with the entire date, we only want to deal with time. So I believe that we can work on the conventions so that even with timezones configured in the application, the dates in the time fields always occur on January 1st to have a better integration with validations and calculations. I understand is not a big deal for the framework, is a very particularly use case, but if you guys agreed to me, I can make a PR |
I want to share a small bug with time field from Active Record.
Basically, the bug occurs when ActiveRecord deserialized time field's day at the turn of the day (Example: 23:00) and the current timezone is like
GMT - 2
. After save the record, the active record load the field in 1999-12-31 and this can break validations and comparison.I believe it should be better storage always in 2000-01-01
Steps to reproduce
I can't get a minimal example to work, I appreciate some help with it. But is easy to reproduce with some steps:
Brasília
inapplication.rb
Expected behavior
Actual behavior
it creates end_time in 1999
Edited this OK: Other strange issue with the field is that the timezone is -2 and not -3 (Timezone problem when casting time field #46220).System configuration
Rails version: 7.1.3.2
Ruby version: 3.3.9
Gem PG: 1.5.6
The text was updated successfully, but these errors were encountered: