Add test illustrating mismatched time zone time and zoned datetime

[sffc]

I realized that ZonedDateTime can contain two different datetimes: the "main" datetime and the reference datetime for the time zone.

It's fairly easy to get into this state. For example, someone might pick "Unix epoch" or "current datetime" to put into the fairly obscure at_time function when constructing their TimeZoneInfo, which is almost always wrong.

This might be partially mitigated if we change the reference datetime to be an absolute time (#6238) so that there isn't a categorical mismatch, but it can still happen.

Maybe fine to ignore. If people use infer_zone_offsets, they won't get a specific non-location zone name that is wrong, only not applicable at the given time, which is confusing but not wrong. (However, if they pull the zone variant from isdst, maybe things could go wrong.)

@robertbastian

[robertbastian]

I don't think this is a bug, and I don't think absolute timestamps are the solution here, because they don't solve the problem of having two inputs that need to agree.

We could change the GetField implementations on ZonedDateTime to ignore the .at_time value in favour of the date and time values. This does, however, add a calendar conversion if the ZDT is not in ISO time, and the user will still need to supply that second time, and it will still be used for infer_zone_variant.

I'm leaning more and more in the direction of having infer_zone_variant happen internally. I have yet to find a client who can actually guarantee a rearguard isdst anyway.

[sffc]

Discussed: OK to ignore this edge case in 2.0