Issue #21301 has been updated by dodecadaniel (Daniel Colson). Ah yeah, rolling over seconds seems trickier. I think the time with the offset doesn't have to deal with all that because it doesn't set the `vtm` struct right away. Instead, it only sets the `timew` (a kind of timestamp) and then calculates the `vtm` later as needed based on the `timew`. The `vtm` -> `timew` -> `vtm` round trip is enough to normalize everything (and `timegmw` and `gmtimew` are leap-second aware, etc.). The UTC time tries to put together and set the `vtm` struct directly upfront and then sets `tobj->vtm.tm_got = 1`. Changing `tm_got` from `1` to `0` is enough to get the UTC code behaving like the offset code, but I assume there's some cost to that. Possibly worth it for better accuracy though? I can explore that more if it seems worthwhile. It'd save us from need to do `vtm_day_wraparound` too. ---------------------------------------- Bug #21301: Invalid Dates Accepted When Using "UTC" in Time.new https://bugs.ruby-lang.org/issues/21301#change-112885 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- 2025-04-31 does not exist, but, when creating a time object with the "UTC" zone, the value is accepted without error: ```ruby Time.new(2025, 4, 31, 0, 0, 0, "UTC") #=> expected: 2025-05-01 00:00:00 UTC #=> actual: 2025-04-31 00:00:00 UTC ``` In contrast, using the "+00:00" time zone works as expected and rolls the date over to 2025-05-01: ```ruby Time.new(2025, 4, 31, 0, 0, 0, "+00:00") # => 2025-05-01 00:00:00 +0000 ``` Note that 2025-04-30T24:00:00Z is correctly rolled over to 2025-05-01T00:00:00Z. And 2025-04-31T24:00:00Z is rolled over to 2025-04-01! ```ruby Time.new(2025, 4, 30, 24, 0, 0, "UTC") #=> 2025-05-01 00:00:00 UTC # OK Time.new(2025, 4, 31, 24, 0, 0, "UTC") #=> 2025-04-01 00:00:00 UTC # What? ``` -- https://bugs.ruby-lang.org/