boa-dev
Automated timezone testing
Right now we have a list of ZonedDateTimes that we test, and we add to them occasionally, like in https://github.com/boa-dev/temporal/pull/499. Beyond testing the to_string roundtripping (which will exercise a lot of the timezone code), we have some specific tests for some of these, usually picked up from test262.
It would be nice to design a test that tests most functionality and is relatively robust.
An idea would be that we select a bunch of epoch times. Some times in the far past, some times in the far future, some times around the epoch (positive, and negative, and one in each season), and some times in/around modern times (same).
Then, for each time zone, we should obtain that ZDT, and obtain its previous/next transitions, add ±1ns to those, obtain their previous/next transitions, ensure that the ones that should be the same are the same and the ones that should be different are different.
Then for every ZDT in the set, check that it roundtrips via to_string and probably also via the epoch value.
Then, strip out the explicit offset, and for ZDTs that are not within an overlap transition (easy to check which transition is overlap from the offsets on the ±1ns times), check that it still roundtrips with disambiguation values set to Reject.
There's probably more we can test, but this is a good start.
Could be nice to hook this up to a fuzzer, too.
We also can test against chrono, which is what the zoneinfo64 crate does (https://github.com/unicode-org/icu4x/pull/6842)
I'm not against bringing chrono in as a dev dependency for constistency. Although, it would be nice to get the current zoneinfo crate to a more stable place where we could test against that.
@nekevss honestly at this point I think we should just reuse the icu4x zoneinfo64 crate, it's closer and is what we plan to use for FFI zoneinfo provider
@nekevss Against zoneinfo64: It's unclear to me if the current zoneinfo crate is needed if we have icu4x/zoneinfo64.
It's mainly meant to provide tooling for someone to create their own provider if someone has a specific need for it and also used to create a CompiledZoneInfoProvider or whatever it would be called.
The two are not really related beyond you could probably use zoneinfo to compile data and create a zoneinfo64 provider if need be.
Ah, it's for tzdb zoneinfo files, not zoneinfo64. I see.
Yeah, cross-testing between all these providers would be cool.