ActiveRecord time field issue with timezone about rails

[matthewd]

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 end < start is actually quite defensible, and the opposite would be more surprising -- the problem happens back during the save, where time's storage limitations truncate away the future-ness.

I don't remember how timetz fits in here, but it might help?

[mkbehbehani]

@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 details

Expectation

We want to work with a time of day, no date involved. This comparison should be true: end_time 22:00 > start_time 12:00

Problem

The Ruby Time and ActiveSupport::TimeWithZone include date. They represent a specific point in time, not the concept of Time of Day.

Time.new => 2024-04-29 17:35:36.866882654 +0000

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 time type (time of day-no date) instead of timestamp (both date and time), you may run into this as it is cast back into a Time or TimeWithZone object and a date is applied.

Approach I've used

• Using the ToD :time_only ActiveRecord attribute for Time of Day representation in application logic
• In Postgres, using the time column type.
• Timezone config for both Rails and Postgres set to UTC and performing changes into desired local timezone before read/write/comparison using .in_time_zone(location_timezone).

[zenspider]

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?

[PedroAugustoRamalhoDuarte]

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