I had such an aha! moment this afternoon that I thought I'd share it.
This test case was failing for me, and I was positive that I hadn't made any changes which would affect that part of the system:
The trick here is when I was running the test: March 9, 2013, at 1:55pm EST. Turns out that tonight is daylight savings, when we "spring ahead" and lose an hour, and of course 23 hours does not a standard day make!
1 comment:
Sounds like an implementation problem in one of the date- or interval-related methods. Under the hood, they should be working in time zone and daylight savings time independent ways that understand that the start and end times, even though numerically identical for most human purposes, have an associated UTC offset that needs to be accounted for. The most common source of this is failing to use locales when manipulating dates.
Post a Comment