Date.current vs Date.today in Ruby
Ruby provides two methods to get the current date: Date.today and Date.current. In a plain Ruby script they're the same, but in a Rails app they can return different dates depending on your timezone configuration -- which can cause subtle, hard-to-reproduce bugs in date-sensitive queries.
# server's system timezone
Date.today
# Rails app timezone (config.time_zone)
Date.current
Date.current is defined in ActiveSupport:
def current
::Time.zone ? ::Time.zone.today : ::Date.today
end
If Time.zone is set (which it almost always is in a Rails app), Date.current returns Time.zone.today. Otherwise it falls back to Date.today.
When Return the Same Value
If your config.time_zone matches the server's system timezone, both return the same date. In development, this is usually the case since your machine's timezone and the app timezone are likely aligned.
This is why the bug often hides until production.
When Return Different Dates
scenario: your server is on UTC (GCP defaults to UTC), but your app is configured for a different timezone.
# config/application.rb
config.time_zone = "Asia/Taipei" # UTC+8
At 2025-02-04 23:30 UTC (server time):
Date.today # => 2025-02-04 (server: still Feb 4)
Date.current # => 2025-02-05 (Taipei: already Feb 5)
A full 1-day gap.
Example: Date-Sensitive Query
Say you have a job that checks upcoming appointments after a cancellation, and sends a reminder if a same-day appointment still exists.
# The edge case:
# At 00:10 UTC on Feb 5 (= 08:10 Feb 5 Taipei)
# Date.today => 2025-02-05
# But between 23:00-23:59 UTC on Feb 4, Date.today is still Feb 4
# while Taipei users are already on Feb 5
# A query using Date.today as a cutoff would be 1 day behind
# Wrong
Appointment.where(date: Date.today..)
# Correct
Appointment.where(date: Date.current..)
More concretely:
# User in Taipei cancels at 23:30 UTC (Feb 4)
# Taipei local time: 07:30 Feb 5
# Date.today => Feb 4
# Date.current => Feb 5
upcoming = Appointment.where(
user_id: user.id,
date: Date.current..
)
When Date.today Would Be Fine
If your server timezone and app timezone are the same, they behave identically. Some teams intentionally set both to UTC and handle display conversion at the view layer. In that case, Date.today won't cause issues. but Date.current still reads better and is safer if the config ever changes.
The Alias
RuboCop's Rails/Date cop actually flags Date.today and suggests Time.zone.today as the preferred replacement. Either Date.current or Time.zone.today is fine, they're equivalent.
Time.zone.today
Summary
| Method | Based On | Safe in Rails? |
|---|---|---|
Date.today | Server system timezone | Only if system TZ == app TZ |
Date.current | config.time_zone | Yes |
Time.zone.today | config.time_zone | Yes |
In a Rails app, always use Date.current. Reserve Date.today for plain Ruby scripts where there's no Time.zone configured.