Bug #18274: Time.new initializes the date incorrectly after a leap day with a positive UTC offset

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -
• ruby -v: ruby 3.1.0dev (2021-10-27T17:00:25Z master 30942c19c0) [x86_64-linux]
• Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN

[philross (Phil Ross)]

With 3.1.0dev revision 30942c19c0, Time.new can initialize the date incorrectly on the day following a leap day. The year 2000 is a leap year. 2000-03-01 00:00:00 +01:00 is considered to be 2000-02-29 00:00:00 +0100:

Time.new(2000, 3, 1, 0, 0, 0, 3600)
#=> 2000-02-29 00:00:00 +0100

Ruby 3.0.2 returns the expected result:

Time.new(2000, 3, 1, 0, 0, 0, 3600)
#=> 2000-03-01 00:00:00 +0100

UTC times and negative UTC offsets return the expected results with 3.1.0dev:

Time.utc(2000, 3, 1, 0, 0, 0)
#=> 2000-03-01 00:00:00 UTC
Time.new(2000, 3, 1, 0, 0, 0, -3600)
#=> 2000-03-01 00:00:00 -0100

Any time of day at or later than the offset also returns the expected results with 3.1.0dev:

Time.new(2020, 3, 1, 0, 59, 59, 3600)
#=> 2020-02-29 00:59:59 +0100 (incorrect)
Time.new(2020, 3, 1, 1, 0, 0, 3600)
#=> 2020-03-01 01:00:00 +0100 (expected)
Time.new(2020, 3, 1, 1, 59, 59, 7200)
#=> 2020-02-29 01:59:59 +0200 (incorrect)
Time.new(2020, 3, 1, 2, 0, 0, 7200)
#=> 2020-03-01 02:00:00 +0200 (expected)

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Assigned
• Assignee set to nobu (Nobuyoshi Nakada)

This appears to be caused by bf789af28a3b7108186743f3cb4fd2f649afdd20. Reverting the commit fixes the issue. Assigning to @nobu (Nobuyoshi Nakada) to determine whether he wants to revert or try to debug.

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Closed

Applied in changeset git|1d666ed50f8b4b3779583381882a0b3edd3cff0e.

---

Fix leap day with UTC offset [Bug #18274]

struct vtm::year is a Ruby integer instance, but not a C integer
type.