Closed georgd closed 2 years ago
Yes. I'm afraid I haven't found a way to resolve this correctly yet.
Is it safe to manipulate the tests to make them pass?
Yes. it's difficult for me to test it on my timezone. Please feel free to submit MR to make the test account for the error (moving the case to different month or comment out but document the behavior is also an option)
@wanasit is there anything that can be done to fix this? I see it's closed but it doesn't seem to be resolved - is there some commit which was believed to resolve this? If so, it doesn't seem to fully fix it.
It worked entirely correctly in 1.4.4
- but the 2.x
versions seem to have this problem.
Even if we set result.start.assign('hour', 12)
- the .date()
method returns 1pm
instead of 12pm
.
Specifically we can instigate this with strings like in 1 month
(with the current date being Feb. 18 and us being in US Eastern time)
This was originally reported in https://github.com/wanasit/chrono/pull/434 and partially fixed with https://github.com/wanasit/chrono/commit/e3b76090e75a95e92bc821ec72ddf367db66b8ac.
Some tests fail when the system is located in a timezone where a daylight saving time switch occurs between a reference or source date and the target date. The target date will be an hour off of what is expected. This is mathematically correct but breaks the tests. In most cases, it’s just the hour that’s off (and the timeZoneOffset) but in some cases it’s even the day (when the source time is midnight, like in https://github.com/wanasit/chrono/blob/61ae8a34ba1beb736d86f11d86a074f7568ba239/test/en/en_time_units_ago.test.ts#L174).
Is it safe to manipulate the tests to make them pass?
Here’s the list of the failing tests: