TimeZoneInfo should use DateTime

[sffc]

It still uses (Date<Iso>, Time).

@robertbastian

[sffc]

Let's decide on #6238 first.

[robertbastian]

I don't know, should it? .at_time could accept

• (Date<Iso>, Time)
• Date<Iso>, Time
• DateTime<Iso>

I don't really see a point of using DateTime. We have the type for IXDTF parsing, and because in datetime we cannot use multiple arguments. If you look at the chrono_jiff example, we're separately building a Date and a Time, what's the point of wrapping it into a dumb DateTime just to pass it across the API?

[sffc]

#6235

• @sffc It could be ZonedDateTime<Iso, Option<UtcOffset>>
• @robertbastian I don't think we should have two UtcOffsets in TimeZoneInfo.
• @sffc Yeah, ok. It makes sense to re-use the existing Option<UtcOffset> field. So then let's make the type DateTime<Iso>?
• @robertbastian DateTime and ZonedDateTime are good output types for the parser and an input to DateTimeFormatter because they need to be one argument. But here, it can be two separate arguments. I don't want to overuse them
• @sffc I prefer thinking of this model as, anywhere we need a tuple of date and time, we use the DateTime named tuple. We don't selectively downgrade to plain tuple or separate parameters
• @robertbastian In FFI we always do, that would be more consistent
• @sffc Yeah, these are Rust types
• @robertbastian If you follow a rust_link from FFI you'll see a Rust signature that does not match the FFI signature, and a type that you cannot construct in FFI
• @sffc The TimeZoneInfo::LocalTime is actually a datetime. It isn't conceptually a date/time tuple; it is a PlainDateTime.
• @robertbastian - That statement doesn't make any sense, we don't distinguish between date+time and datetime, and I don't see a conceptual difference either
• @sffc It's really a timestamp. It's a local timestamp because we don't have an offset all the time.
• @robertbastian - and that can be perfectly well represented by a date and a time

No conclusion at this time.