In my environment, with sequel_pg, your example gives: 2021-11-07 01:35:44 -0700 2022-02-21 08:22:37 -0800 2021-11-07 01:35:44 -0700 2021-03-23 08:36:22 -0700 2021-11-07 01:35:44 -0700
With NO_SEQUEL_PG, your example gives: 2021-11-07 01:35:44 -0800 2022-02-21 08:22:37 -0800 2021-11-07 01:35:44 -0800 2021-03-23 08:36:22 -0700 2021-11-07 01:35:44 -0800 So I don't see the issue you are seeing where the same timestamp can return different values. However, the behavior does change when sequel_pg is used. As the underlying timestamp value is ambiguous, I would consider either behavior correct, and therefore I don't think is a bug. The cause of the behavior change is likely due to the use of mktime/rb_time_timespec_new in sequel_pg. The moral of this story is to use timestamptz instead of timestamp if you care about timestamp offsets. Sequel ships with a pg_timestamptz Database extension that will use timestamptz instead of timestamp for Time/DateTime generic types. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to sequel-talk+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sequel-talk/CADGZSSecRuD5yf%2Bo3iMFcCF7weid931UopT-S6mMGkr-E99H6w%40mail.gmail.com.
