New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add additional checks for AlternateTime #789
base: main
Are you sure you want to change the base?
Conversation
Thanks for this @x-hgg-x - I'll need a bit of time to understand this better, however one thing I noticed was:
Is this empirically always the case in the IANA tzdb? From memory while testing I'd come across cases where there were regular transitions that switched orders, although potentially these checks only apply to the rules that are used once all the hard-coded transition times are exhausted? |
Yes all the rules in the IANA database pass the check. In the case that a new version of the database adds an invalid rule, the tzdb crate will not compile since the check is done at compile time in For information, if the order of the DST start and end time is switched between consecutive years, the current behavior of glibc and musl is to have a new transition at the new year on UTC (not on local time like the other transitions defined by the rule): export TZ="STD5DST,J87,M3.5.0"
date --date=@1609459199 +"%F %T %:z %Z"
date --date=@1609459199 +"%F %T %:z %Z" --utc
echo
date --date=@1609459200 +"%F %T %:z %Z"
date --date=@1609459200 +"%F %T %:z %Z" --utc Output:
|
Yes the check only applies to the extra rule after the last transition, defined by a POSIX |
470784d
to
f5df0f0
Compare
With regards to this - would you mind adding a test that parses all the available files in the systems timezone database? That way it runs in the CI here, meaning we would be notified here if the validation is causing an issue. (Separately, I'll schedule the CI to run at least once a day on |
Done in e4ebfe4. |
057d03e
to
e4ebfe4
Compare
If we're "statically" validating that the tzdb zones pass some particular test, do we still need run-time verification? Seems like overkill to me. |
One potential benefit of the runtime validation is that we could then make more assumptions about the structure of the files and therefore change fallible functions to be non-fallible, provided the validation has already passed, which might simplify some of the downstream code. |
I don't think there is any compile-time validation of the tzdb zones at the moment in the |
4a686cc
to
39cbf40
Compare
Perhaps we can have a feature (enabled by default) that does the runtime validation? Then for users who need better performance they could disable this (with the caveat that dependencies may cause it to be engaged anyway). We already do some runtime validation, so that could potentially be later gated by that feature as well. Eventually some of these validation rules could potentially be shared with |
A quick benchmark on my PC for the |
Thanks for contributing to chrono!
Please consider adding a test to ensure your bug fix/feature will not break in the future.
This PR adds additional checks for the
AlternateTime
struct in thetz-info
module, not existing in the initial implementation (see #677 (comment)).