Zenn
🕌

RubyのDate / Time / DateTimeの違いを知らないと痛い目見るよ！のお話

2024/11/13に公開
Rails
Ruby
初心者
プログラミング
タイムゾーン
tech

はじめに

「あれ？保存した時刻がずれてる・・・」
「カレンダー機能がうまく動作しない😭」
「Time.nowとTime.current、どっちを使えばいいんだろう？」

既存システムを保守メンテナンスしていると、日付や時刻に関する問題はつきものです。
特にRubyとRailsには複数の時刻処理の仕組みが存在し、その使い分けを誤るとバグの温床になってしまいます。
この記事では、現場でやりがちな時刻まわりの問題とその解決方法について、実践的な観点から解説していきます！

1. 基本的な日付・時刻クラスの解説

Time クラス

基本情報

  • Ruby標準ライブラリ（require不要）
  • 日付と時刻の両方を扱える
  • タイムゾーンをサポート
  • ミリ秒単位の精度
  • Railsアプリケーションで最も推奨
# 基本的な使い方
current_time = Time.now       # => 2024-01-01 12:00:00 +0900
future_time = Time.new(2024, 12, 31, 23, 59, 59)

# Rails環境での推奨される使い方
current_time = Time.current   # config.time_zoneの設定に従う
parsed_time = Time.zone.parse("2024-01-01 12:00:00")

Date クラス

基本情報

  • requireが必要（require 'date'）
  • 日付のみを扱う（時刻は扱わない）
  • タイムゾーンの概念なし
  • メモリ効率が良い
  • カレンダー機能に適している
require 'date'

# 基本的な使い方
today = Date.today
specific_date = Date.new(2024, 1, 1)
parsed_date = Date.parse("2024-01-01")

# 日付の計算
tomorrow = today + 1
yesterday = today - 1

DateTime クラス（非推奨）

基本情報

  • requireが必要（require 'date'）
  • 日付と時刻の両方を扱える
  • 現在は非推奨（Timeクラスの使用を推奨）
DateTimeクラスが非推奨となった理由

[歴史的な背景]

  • 以前のRubyのTimeクラスには制限があった。

    • 1970年以前の日時を扱えない

    • システムのタイムゾーン設定に依存

    • プラットフォームによって動作が異なる

      ⬇️⬇️⬇️

  • これらの制限を解決するためにDateTimeクラスが作られたが、DateTimeクラスには下記のようなデメリットがあった

    • Timeクラスと比べて処理が遅い
    • メモリ使用量が多い

  • ⭐️Ruby 1.9.2以降、Timeクラスが大幅に改善された

    • 1970年以前の日時も扱えるようになった
    • タイムゾーンのサポートが強化された
    • プラットフォーム依存が解消された
    • より高精度な時刻処理が可能になった

※紛らわしい動作

  • TimeクラスとDateTimeクラスで動作が異なる場合がある
  • タイムゾーンの扱いが異なる

上記の理由より、DateTimeクラスが非推奨となった

require 'date'

datetime = DateTime.now
specific_datetime = DateTime.new(2024, 1, 1, 12, 0, 0)

2. Railsでの設定方法とタイムゾーンの基礎知識

config.time_zoneについての基本的な理解

タイムゾーン設定の重要性

  • アプリケーション全体の時刻表示の基準となる重要な設定
  • ユーザー体験に直接影響するため、プロジェクト初期に適切な設定が必要

設定方法

# config/application.rb
module App
  class Application < Rails::Application
    # タイムゾーンの設定
    config.time_zone = 'Tokyo'  # 日本向けアプリケーションの場合
    
    # データベースのタイムゾーン設定
    config.active_record.default_timezone = :utc
  end
end

利用可能なタイムゾーン一覧の確認方法

$ rails time:zones:all

設定値の動作確認

# Railsコンソールでの確認
# アプリケーションの設定値を確認
> Rails.application.config.time_zone
=> "Tokyo"

# 現在のタイムゾーンを確認
> Time.zone.name
=> "Asia/Tokyo"

> Time.current
=> Mon, 11 Nov 2024 10:00:00 JST +09:00

タイムゾーンの3構造

  1. アプリケーション設定（config.time_zone）

    • ユーザー向けの時刻表示に影響する
    • Time.zone.nowやTime.currentの動作を決定する

  2. データベース設定（config.active_record.default_timezone）

    • :utcまたは:localのみ選択可能
    • created_at/updated_atの保存形式に影響する
    • :utcが推奨される

  3. システム（OS）のタイムゾーン

    • Time.nowの動作に影響する
    • 環境変数TZで設定する

環境ごとの注意点

1. Docker環境での設定

問題点

  • Dockerコンテナのデフォルトタイムゾーンはutcが基本
  • アプリケーションの設定とコンテナの設定が異なると予期せぬ動作の原因になる

設定方法

# docker-compose.yml
services:
  web:
    environment:
      - TZ=Asia/Tokyo

# Dockerfile
ENV TZ=Asia/Tokyo

確認方法

# コンテナ内でタイムゾーンを確認
$ docker-compose exec web date

3. 実践的な使い方とベストプラクティス

推奨される使い方

# 現在時刻の取得
Time.current   # ○ 推奨
Time.zone.now  # ○ 推奨
Time.now       # × 非推奨（環境依存）

# 文字列のパース
Time.zone.parse("2024-01-01 12:00:00")  # ○ 推奨
Time.parse("2024-01-01 12:00:00")       # × 非推奨

# 日付の取得
Date.current   # ○ 推奨
Date.today     # × 非推奨

データベースとの連携

時刻データの保存

# DBの保存時のタイムゾーン設定
config.active_record.default_timezone = :utc  # 推奨設定

注意すべきポイント

  • DBには通常UTCで保存される（:utc推奨）
  • 表示時にアプリケーションのタイムゾーンに変換される
  • 9時間の差が生じる可能性がある（UTC ⇔ JST）

設定反映に必要な手順

  • OSの再起動またはタイムゾーン設定の再読み込み
  • Railsサーバーの再起動
  • Dockerコンテナの再起動（Docker環境の場合）

まとめ

Railsで時間を扱う際に気をつけなければいけないこと

  1. プロジェクト初期に適切な設定を行う

    • アプリケーションのタイムゾーンを設定する
    • Docker環境の設定を行う
    • データベースのタイムゾーンを設定する

  2. 一貫性のある時刻処理を設定する

    • Time.currentを使用する
    • 明示的なタイムゾーンを指定する
    • DBとの整合性を確認する

  3. 開発時の注意点

    • 環境による違いを考慮する

  4. 定期的な確認

    • タイムゾーンデータの更新を確認する
    • 各環境での動作確認を行う
    • ログやデバッグ情報で確認する

参考

class Time
class Date
class DateTime
タイムゾーンの設定
Railsのタイムゾーン設定について
【Rails6】application.rbの初期設定(タイムゾーン・I18n・Zeitwerk)
RailsではTime.parseではなくTime.zone.parseを使おう

Discussion