It's possible for a Zoned value to produce a string that cannot be successfully parsed back into an equivalent Zoned value #386
Description
The following code panics on MacOS 12.6.5:
Zoned::new(
"2087-12-31T23:00:00Z".parse().expect("fine"),
TimeZone::get("Africa/Casablanca").expect("fine"),
)
.to_string()
.parse::<Zoned>()
.expect("panics");The error is: parsing "2088-01-01T01:00:00+02:00[Africa/Casablanca]" failed: datetime 2088-01-01T01:00:00 could not resolve to a timestamp since 'reject' conflict resolution was chosen, and because datetime has offset +02, but the time zone Africa/Casablanca for the given datetime unambiguously has offset +01
From a quick check, it looks like this starts happening for years 2087.., but I haven't checked extensively. I tried checking on the playground but it doesn't configure a tzdb.
I looked for a way to print the full timezone info, but couldn't find one. It may be an option worth considering for diagnostic purposes?