Cromefire_

So not only specifically for OpenAPI, but in general to represent [RFC3339](https://tools.ietf.org/html/rfc3339#page-8) Datetimes (which is meant to be the Internet standard). You can of course use an `Instant` here, but...

Which does result in the loss of information

> I compared how java.time handles that. We're discussing the DST point too much and let's better focus on the core ZonedDateTime aspect. I think aligning with java's behavior makes...

> If you want to keep the API as small as possible then here’s some provocative food for thought: If you had ZonedDateTime instead of Instant maybe people wouldn’t be...

> You mean that laws can change the meaning of the past for a ZonedDateTime (in UTC)? Yes. For UTC this might not be a problem, but for other timezones...

> 1. It's also not ambiguous with `RegionDateTime` when adding the optional offset In which case it would just be a OffsetDateTime right? And all the calendar usage traits would...

In that case I'd stick to the TC39 proposal, that looks quite good (there's also usually with at lot of peoples checking it).

@dkhalanskyjb > > The same argument can be made for date + time. > > It can't because 1) waiting for an hour at 23:31 will start the next day...

> True. However, there's a difference between introducing an OffsetDateTime or a ZonedDateTime with their whole semantics and behavior, and adding a small wrapper that's almost like a pair, but...

> > The helper functions definite the semantics of the class, so I don't see a difference here. > > The difference is that there are fundamental classes that define...