Previously, all between functions operated on the result
of ->datetime/utc on their inputs. This is a problem for
moments, since it makes the date computations timezone-sensitive.
For example, the bug report I received had:
returning 0 instead of the expected 1. That's because that day
happens to include the start of daylight saving time, so the
local timeline is missing an hour. Consequently, when we
translate these to UTC datetimes, they're within a day of each
other.
The fix is to transform the second argument into a local datetime
based on the requirements of the first argument. In most cases,
the requirements are trivial; dates and datetimes are always
transformed using ->datetime/local, no matter what the first
argument is. But if both arguments have time zones, then the second
argument is first adjusted into the time zone of the first. Then,
the local datetime component is used.
Previously, all
betweenfunctions operated on the result of->datetime/utcon their inputs. This is a problem for moments, since it makes the date computations timezone-sensitive. For example, the bug report I received had:returning 0 instead of the expected 1. That's because that day happens to include the start of daylight saving time, so the local timeline is missing an hour. Consequently, when we translate these to UTC datetimes, they're within a day of each other.
The fix is to transform the second argument into a local datetime based on the requirements of the first argument. In most cases, the requirements are trivial; dates and datetimes are always transformed using
->datetime/local, no matter what the first argument is. But if both arguments have time zones, then the second argument is first adjusted into the time zone of the first. Then, the local datetime component is used.