テストでのタイムゾーン表記を US/Eastern から America/New_York に置換

rails/rails

Rails のテストスイートにおいて、PostgreSQL のタイムゾーン指定に使われていた US/Eastern が IANA tzdata の更新で非推奨となり接続エラーを引き起こしていた。本 PR はその箇所を America/New_York に置き換え、テスト実行時の ActiveRecord::ConnectionNotEstablished を防止するものです。

背景

US/Eastern が PostgreSQL の有効タイムゾーン名から除外されたため、最新ビルドの PostgreSQL(例: Homebrew)でテストを走らせると TimeZone パラメータが無効 となり接続が失敗していました。Issue #57586 で報告された通り、ActiveRecord::ConnectionNotEstablished が発生し CI が落ちるケースが確認されていました。この変更は、広くサポートされている IANA の正規名 America/New_York に置換することで、すべての環境で安定したテスト実行を実現します。

技術的な変更

postgresql_adapter_test.rb の定数更新

テストで使用されている KNOWN_SERVER_DEFAULTS 定数のタイムゾーンオプションが -c TimeZone=US/Eastern から -c TimeZone=America/New_York へ変更されました。これにより、PostgreSQL 接続時に送られる SET TIME ZONE コマンドが有効な名前になるため、接続エラーが解消されます。

- KNOWN_SERVER_DEFAULTS = "-c TimeZone=US/Eastern -c IntervalStyle=postgres -c standard_conforming_strings=on -c client_min_messages=notice"
+ KNOWN_SERVER_DEFAULTS = "-c TimeZone=America/New_York -c IntervalStyle=postgres -c standard_conforming_strings=on -c client_min_messages=notice"

test_case.rb のデフォルトタイムゾーン引数変更

テストユーティリティ with_env_tz のデフォルト引数が "US/Eastern" から "America/New_York" に変更され、環境変数 TZ を設定する際に常に有効なタイムゾーンが使用されます。これにより、テストケース全体で タイムゾーン依存のロジックが期待通りに動作し、ローカル環境でも同様の結果が得られます。

- def with_env_tz(new_tz = "US/Eastern")
+ def with_env_tz(new_tz = "America/New_York")
   old_tz, ENV["TZ"] = ENV["TZ"], new_tz
   yield
 ensure
   ENV["TZ"] = old_tz
 end

設計判断

この PR は 既存テストコードの文字列リテラルを置換 するシンプルなアプローチを採り、ファイル構造やテストロジックに新たな抽象化層を導入しませんでした。そのため、後方互換性へのリスクは極めて低く、変更の影響範囲はテストコードのみです。また、代替タイムゾーン名をハードコードすることで、外部設定や環境差分による不安定要因を排除し、テストの再現性を向上させています。

まとめ

IANA tzdata の更新で廃止された US/Eastern をテストコード内で America/New_York に置換することで、PostgreSQL 接続時のタイムゾーンエラーを根本的に解消しました。変更はテストファイルの定数とユーティリティメソッドの2か所に限定され、既存機能への影響はなく、安定したテスト実行が維持されます。

記事メタデータ

Generated by:
gpt-oss-120b for DiffDaily
LLM Trace:
5f800e39

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

品質レビュー結果

Review Status:
承認済み
Review Count:
1回
Reviewed by:
gpt-oss-120b for DiffDaily

Review Criteria:

記事構成 ✓ PASS

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

リード文→背景→技術的な変更→設計判断(任意)→まとめの3部構成が明確に存在し、各要素が適切に記述されています。

カスタムMarkdown構文 ⚠ WARNING

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

コードブロックのファイル名付きシンタックスハイライトは正しい形式ですが、GitHubリンクの記法が統一されていません。PRリンクは "PR #57587" となっており、推奨の "[#57587]" 形式ではありません。また、Issue #57586 がリンク化されていません。

対象読者への適合性 ✓ PASS

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

Rails エンジニア向けの専門的な内容で、過度な基礎説明はなく適切です。

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

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

各セクションが総論→各論→結論の流れになっており、段落はトピックセンテンスで始まり 1 段落1トピック、長さも適切です。空行で区切られています。

Diff内容との照合 ✓ PASS

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

記事内のコードブロックは提供された Diff と完全に一致しており、変更箇所・ファイル名とも合致しています。

技術用語の正確性 ✓ PASS

技術用語の正確な使用

使用されている用語(例: IANA tzdata, PostgreSQL, ActiveRecord::ConnectionNotEstablished 等)は PR 内容と合致し、誤用はありません。

説明の技術的正確性 ✓ PASS

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

技術的な説明は PR の背景・目的・変更点と整合し、因果関係も正しく述べられています。

事実の突合 ✓ PASS

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

記事の全ての主張は PR タイトル、説明、Diff に裏付けられており、ハルシネーションは検出されません。

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

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

PR番号 #57587、Issue番号 #57586、ファイルパス、コード行の内容など、数値・固有名詞は正確です。

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

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

記事タイトルは PR タイトルの意味を日本語で正確に表現しており、一致しています。

外部知識の正確性 ✓ PASS

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

記事内に PR で言及されていない外部知識(LTS、リリース日程等)は含まれていません。

時間表現の正確性 ✓ PASS

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

時間表現は使用されておらず、PR の記述と矛盾する表現もありません。