Unexpected delta math surrounding DST

[ssimms]

In DateTime 1.50, when using delta_ms and delta_minutes to get the number of minutes between certain sets of times last Friday and this past Monday (on either side of the DST changeover), I ended up with a result that was 1440 minutes (24 hours) larger than expected.

See the attached test cases for two examples that are working:

• Fri 12:30 to Mon 12:30 = 4320 minutes (72 hours)
• Fri 12:30 to Mon 12:40 = 4330 minutes (72 hours plus 10 minutes)

... and one that isn't:

• Fri 12:30 to Mon 12:20 should return 4310 minutes (72 hours minus 10 minutes), but actually returns 5750 minutes (96 hours minus 10 minutes).

I'm not suggesting that it should be 73 hours instead of 72 -- I see that DateTime does some relative math rather than being pedantic, and I'm fine with that, especially when DST is involved. "Off by 24 hours" seems like a bug, though.

datetime-dst-test.txt

[autarch]

Yes, this is definitely a bug. Thanks for the report! I'm amazed no one else has reported this, since it probably goes back 10+ years.

[autarch]

I started to fix this but then I wondered what the fix is.

Arguably all three operations are wrong. Shouldn't we come up with 73 hours +/- 10 minutes? The reason it doesn't do that currently is that it's effectively operating on UTC internally rather than the local time (I say effectively because even if you look at local values, if you do it by counting differences in days rather than hours you end up treating them as UTC).

But changing this might break tons of code, so I guess I'll just make the small fix and add a note to the docs.

[autarch]

Wait, no, it's not operating on UTC, it's operating on the display time. Ugh. It's really quite wrong.