This error comes up seemingly only when a datetime is 23 hours prior to dst switch. The following example using local time is based in "America/Chicago"
var dateTime= lux.DateTime.local(2019,3,9,3,0,0,0);
dateTime.plus({hours:24})
returns 2019-03-10T03:00, but I would expect 2019-03-10T04:00, since an hour is skipped due to the dst switch. This is highlighted by the fact that dateTime.plus({hours:23}) returns the same datetime as dateTime.plus({hours:24}) for this case. I was able to revert to release 1.17.3, and plus worked as I would have expected.
I can't reproduce this in Chrome, where I get "2019-03-10T04:00:00.000-05:00". What browser (or Node version) and what version of Luxon?
ahh sorry for my late response. I am using node v12.14.1 I can try with the current recommended (12.16.1) . here is my script verbatum
const lux = require('luxon')
var oneAm = lux.DateTime.local(2019,3,9,3,0,0,0);
console.log(oneAm.plus({days:0, hours:23}).c.hour )
console.log(oneAm.plus({days:0, hours:24}).c.hour )
If the first log matches the second log, you have reproduced the issue. Ofcourse, this only works for central time zone.
Ah, I was able to reproduce it this time; trick was the days: 0 part. Yeah, this is a bug.
For future me: issue is almost certainly the shiftTo at the top of adjustTime, which is collapsing the 24 hours into the days key. May have broken in ee70b8b8b2f3c75b863f2fb35e9b8327d5f83eec. Removing the shiftTo would break fractional days, since that's how we redistribute the fractional part into the lower-order pieces.
Fixed in #722
Most helpful comment
Ah, I was able to reproduce it this time; trick was the
days: 0part. Yeah, this is a bug.For future me: issue is almost certainly the
shiftToat the top ofadjustTime, which is collapsing the 24 hours into thedayskey. May have broken in ee70b8b8b2f3c75b863f2fb35e9b8327d5f83eec. Removing theshiftTowould break fractional days, since that's how we redistribute the fractional part into the lower-order pieces.