UTC+なんなのか意識してレビューとコーディングをしたい

Time.current.class は => ActiveSupport::TimeWithZone であり現地時間を取得できる
Date 型は世界標準時 UTC + 0 を参照する

そのため to_date を用いて型変換しない場合は UTC+9 の時間を追加すると比較できる

[78] pry(main)> product.start_date
=> Wed, 29 Nov 2023

[79] pry(main)> product.start_date <= current_day + 8.hour
=> false

[80] pry(main)> product.start_date <= current_day + 9.hour
=> true

境目は 8時間59分59….. ＋9時間すると正しく動作する

実際にあった怖い話

DateTimeオブジェクトとTimeオブジェクトをコード内で同列に扱って
日付判定ロジックでミスった話

公開日が　11/29日
今日の日付 11/29日

current_day = Time.current.beginning_of_day
product.start_date = Wed, 29 Nov 2023

シンプルに気持ちだけ伝えると
start_date == product.start_date は True になってほしい
意識せずレビューしていたら、適当にLGTMしてしまいそうになる。

[48] pry(main)> product.start_date == current_day
=> false

[49] pry(main)> product.start_date
=> Wed, 29 Nov 2023

[50] pry(main)> current_day
=> Wed, 29 Nov 2023 00:00:00.000000000 JST +09:00

現実はそうもいかず
同じ日付でも型が違うと悲しい気持ちになる

DBに時間指定なしで日付だけ保存している場合 Wed, 29 Nov 2023
to_date で変換しないと正しく比較できない

[49] pry(main)> product.start_date
=> Wed, 29 Nov 2023

[54] pry(main)> current_day.to_date
=> Wed, 29 Nov 2023

[53] pry(main)> product.start_date == current_day.to_date
=> true

デバッグも比較演算子バグかな？という目線で見てしまう

product.start_date <= Time.current

このように書いていて、コード的には開始日が今日以降かどうかという感じで
演算子が原因でバグかなー？という目線でコードをみていると

比較演算子のバグじゃないから別の部分のエラーかな？と罠にハマりそうになりますね