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
このように書いていて、コード的には 開始日が今日以降かどうかという感じで
演算子が原因でバグかなー?という目線でコードをみていると
比較演算子のバグじゃないから別の部分のエラーかな?と罠にハマりそうになりますね