`this_week?` に `start_day` 引数を追加し、`all_week` との一貫性を確保

rails/rails

this_week? にオプショナルな start_day 引数が追加され、all_weekbeginning_of_weekend_of_week と同じインターフェースに統一されました。これにより、グローバル設定を変更せずに呼び出し単位で週の開始曜日を指定できるようになります。

背景

this_week? は同ファミリーの他メソッドと異なり、グローバルな Date.beginning_of_week 設定にしか依存できませんでした。関連メソッドである all_weekbeginning_of_weekend_of_week はいずれも start_day 引数を受け付けており、この非対称性が実用上の制約となっていました。

マルチテナントやi18n対応のアプリケーションでは、米国(:sunday 始まり)と欧州(:monday 始まり)のような異なるロケールを同一プロセスで扱う場面があります。こうした場合に around_action 等で Date.beginning_of_week= を切り替える方法は、並行環境での共有可変状態となりバグを生みやすくなります。また、「月曜始まりの今週」と「日曜始まりの今週」を並べて表示するレポートやダッシュボードでは、グローバル設定の一時的な変更なしにこれを実現する手段がありませんでした。

本変更はデフォルト値を Date.beginning_of_week のままとしており、引数を渡さない既存の呼び出しは挙動が変わらない完全な後方互換変更です。

技術的な変更

activesupport/lib/active_support/core_ext/date_and_time/calculations.rbthis_week? メソッドに start_day 引数が追加され、内部で呼び出す all_week にそのまま渡されるようになりました。

変更前:

# Returns true if the date/time falls within the current week.
def this_week?
  ::Date.current.all_week.include?(to_date)
end

変更後:

# Returns true if the date/time falls within the current week.
# Week is assumed to start on +start_day+, default is
# +Date.beginning_of_week+ or +config.beginning_of_week+ when set.
def this_week?(start_day = Date.beginning_of_week)
  ::Date.current.all_week(start_day).include?(to_date)
end

変更は2行のみのシンプルな差分です。引数を all_week へそのまま委譲する実装のため、all_week が対応している全ての曜日シンボル(:monday:sunday 等)がそのまま利用できます。使用例は以下の通りです:

date.this_week?           # Date.beginning_of_week をそのまま使用(変更なし)
date.this_week?(:sunday)  # 日〜土の週で判定
date.this_week?(:monday)  # 月〜日の週で判定

テストは activesupport/test/core_ext/date_time_ext_test.rbtest_this_week_with_start_day として追加されました。Date.current を 2000年1月5日(水曜日)にスタブし、デフォルト(月曜始まり:1/3〜1/9)と :sunday 指定(日曜始まり:1/2〜1/8)の境界値を各3ケースで網羅しています。

設計判断

既存メソッドの委譲パターンを踏襲する方式が採用されました。this_week? の内部実装はもともと all_week に依存しており、引数を追加してそのまま渡すだけで目的が達成できる構造になっていました。新たなロジックを導入せず、all_week の週範囲計算をそのまま再利用しているため、週の境界判定のロジックが一箇所に集約され続けます。

デフォルト値を Date.beginning_of_week(メソッド呼び出し時に評価されるデフォルト引数)としている点も、他のメソッドと完全に一致しています。これはクラスレベルの設定を動的に参照する既存の設計と整合しており、引数省略時の挙動が従来と変わらないことを保証します。

まとめ

本PRは、this_week? が同ファミリーの中で唯一欠いていた start_day の柔軟性を、わずか2行の実装変更で補完した変更です。グローバル状態に依存せずに週の開始曜日を呼び出し単位で指定できるようになったことで、マルチテナントやi18n対応アプリケーションにおけるスレッドセーフな日付判定が実現できます。

記事メタデータ

Generated by:
Claude Sonnet 4.6 for DiffDaily
LLM Trace:
18421e84

この記事はAIによって自動生成されています。内容の正確性については、必ずソースコードやPRを確認してください。

品質レビュー結果

Review Status:
承認済み
Review Count:
1回
Reviewed by:
Gemini 2.5 Pro for DiffDaily

Review Criteria:

記事構成 ✓ PASS

Title, Context, Technical Detailの存在と明確さ

「総論→各論→結論」の構成が明確です。リード文で要旨を述べ、背景、技術詳細、設計判断で深掘りし、最後にまとめで締めくくるという、模範的な記事構成です。

カスタムMarkdown構文 ✓ PASS

シンタックスハイライト・GitHubリンク記法の正確性

ファイル名付きシンタックスハイライト(```ruby:ファイルパス)やPR番号のリンク記法([PR #56872](URL))が、ガイドラインに沿って正しく使用されています。

対象読者への適合性 ✓ PASS

エンジニア向けの適切な技術レベルと表現

「マルチテナント」「i18n」「共有可変状態」といった用語を適切に使い、専門知識を持つエンジニアを対象とした、簡潔で的確な内容になっています。

パラグラフ・ライティング ✓ PASS

トピックセンテンス・1段落1トピック・段落長

各セクションが要旨を述べるパラグラフから始まり、各段落もトピックセンテンスで始まる構成になっており、非常に高い可読性を実現しています。1段落1トピックの原則も守られています。

Diff内容との照合 ✓ PASS

コードブロックとDiff内容の一致

記事で引用されているコードは、提供されたDiffの内容と完全に一致しています。ファイルパス、変更箇所ともに正確に反映されています。

技術用語の正確性 ✓ PASS

技術用語の正確な使用

PR Descriptionで使われている `multi-tenant` や `shared mutable state` などの技術用語を正確に理解し、記事内で適切に使用できています。

説明の技術的正確性 ✓ PASS

技術的主張の正確性と論理性

後方互換性が保たれる理由(デフォルト引数の設定)や、変更がスレッドセーフな運用に寄与する点など、技術的な説明はすべて正確で論理的です。

事実の突合 ✓ PASS

PR情報による主張の裏付け(ハルシネーション検出)

記事内のすべての主張(背景、技術的実装、設計判断)は、PRのTitle, Description, Diffから裏付け可能であり、ハルシネーションは一切見られません。

数値・固有名詞の確認 ✓ PASS

PR番号・コミットID・バージョン等の正確性

PR番号(#56872)、ファイルパス、テストコードでスタブされた日付(2000年1月5日)など、すべての数値・固有名詞が正確です。

タイトル・説明との一致 ✓ PASS

記事タイトル・説明とPR内容の一致

記事のタイトルは元のPRのタイトル「Add start_day argument to this_week? for consistency with all_week」を忠実に反映しており、記事の内容と完全に一致しています。

外部知識の正確性 ✓ PASS

PRに記載のない外部知識(LTS、サポート状況など)の不使用

記事の内容は完全にPR情報に基づいており、バージョンサポート状況やリリース日程といったPR外の外部知識を持ち込むことなく記述されています。

時間表現の正確性 ✓ PASS

時間表現がPR情報と一致しているか

PR情報に含まれる時間表現(例: recently introduced)を適切に解釈し、記事内で誤解を招くような時間表現の歪曲はありません。