Open ab-pm opened 7 months ago
When .until(…) is called on an invalid Datetime instance, it returns the instance itself instead of an invalid Interval.
.until(…)
Datetime
Interval
To Reproduce
Interval.isInterval(DateTime.now().until(DateTime.invalid('demo'))) // true (ok) Interval.isInterval(DateTime.invalid('demo').until(DateTime.now())) // false! DateTime.isDateTime(DateTime.invalid('demo').until(DateTime.now())) // true!
It seems the bug was introduced in https://github.com/moment/luxon/commit/a2602aa4a315515a848036ec1c67268602b82a1d#diff-5146f40a8c8111b14e5ab3407eff80c7a6d2f3c92a4bf4ccd4647bff32d47e38R1317-R1319 (although even back then, it did sometimes return an interval and sometimes a Duration.invalid()). In diff() and .diffNow() this has been subsequently fixed during a reimplementation, but until still exhibits the unexpected behaviour.
Duration.invalid()
diff()
.diffNow()
until
When
.until(…)
is called on an invalidDatetime
instance, it returns the instance itself instead of an invalidInterval
.To Reproduce
It seems the bug was introduced in https://github.com/moment/luxon/commit/a2602aa4a315515a848036ec1c67268602b82a1d#diff-5146f40a8c8111b14e5ab3407eff80c7a6d2f3c92a4bf4ccd4647bff32d47e38R1317-R1319 (although even back then, it did sometimes return an interval and sometimes a
Duration.invalid()
). Indiff()
and.diffNow()
this has been subsequently fixed during a reimplementation, butuntil
still exhibits the unexpected behaviour.