You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea here is to make it so that:
1. If we are using local time, in a time zone with DST adjustments,
then no matter when we run the test, at least one "X weeks ago"
case will have exactly one DST adjustment between then and now.
(Thus, if our local time can observe #1696, it will.)
2. It is easy to verify that this is so.
The rules are somewhat variable, and adjustments cannot be
approximated as happening every half-year:
- In multiple time zones with DST-related adjustments, an
adjustment and its reversal can be separated by only four months
(November to March).
- Countries may institute rules that may be hard for people not
familiar with them to anticipate. For example, Morocco used to
have DST-related adjustments; when it did, if the (lunar) month
of Ramadan occurred during the usual (Gregorian-based) DST
period, standard time (rather than DST) was in effect during
Ramadan. Thus, in some years, there were four DST-related clock
adjustments.
It is hard to predict (or, at least, I do not know how to
predict) if, or what kind of, new DST adjustments may be put in
place somewhere.
With that said, the current test probably has more intervals than
necessary. Furthermore, if it turns out to be feasible, it may be
better to make this a true unit test by using a set time instad of
`now` to take "X weeks ago" times relative to, and by somehow
specifying or mocking out the time zone, so as to test the tricky
cases in exactly the same way no matter where, when, or in what
local configuration the test is run.
Failure, when it occurs, now looks like:
--- STDERR: gix-date::date time::parse::relative::various ---
thread 'time::parse::relative::various' panicked at gix-date\tests\time\parse.rs:216:9:
assertion failed: `(left == right)`: relative times differ
Diff < left / right > :
[
2024-11-09T04:22:21Z,
< 2024-08-17T04:22:21Z,
< 2024-05-25T04:22:21Z,
> 2024-08-17T03:22:21Z,
> 2024-05-25T03:22:21Z,
2024-03-02T04:22:21Z,
2023-12-09T04:22:21Z,
2024-11-09T04:22:21Z,
2024-08-17T04:22:21Z,
2024-05-25T04:22:21Z,
2024-03-02T04:22:21Z,
2023-12-09T04:22:21Z,
]
Equivalent cases with weeks and minutes were interleaved before,
but now all the "weeks" cases are listed before all the "minutes"
cases, because that produces more readable output when
`pretty_assertions::assert_eq!` is used.
0 commit comments