DateTime string formats / ISO 8601 about openapi3 HOT 8 OPEN

Well, that makes sense. After all, always-Z time is certainly a subtype of ISO8601 time. Can you make a PR for that change?

BTW, did you consider using UNIX timestamps instead of strings? IMO that representation is far more convenient.

from openapi3.

Hi @jwbrew,

My guess is that UTCTime uses this format to specifically indicate that the time zone is always Z. If we switch to format: date-time, the reader of the spec will not know this detail. What do you think?

As for ToParamSchema instance for ZonedTime, I suppose this is a mistake, I will fix that.

from openapi3.

I've changed ToParamSchema ZonedTime instance for now. Let me know what you think about my comment above.

from openapi3.

My guess is that UTCTime uses this format to specifically indicate that the time zone is always Z. If we switch to format: date-time, the reader of the spec will not know this detail. What do you think?

Yup I think that makes complete sense. IIRC I remember thinking something similar some time after posting the original comment. Thanks for making the change to ZonedTime, it's going to make things a whole lot more straightforward now!

from openapi3.

You are welcome!

I'll keep this issue open for some time, to think about it once again later.

from openapi3.

We've just run across this and I wonder whether @maksbotan you've had a chance to think about this some more.

I'm not convinced that the benefit of the client knowing that the timezone is always UTC for UTCTime is worth the tradeoff of not recognizing the format string. In our case, at least, this just creates a big hassle: our generator doesn't recognize UTCTimes as a date, so we have two choices: do some client-side overrides to say, "no, these fields are in fact Date and not string", or server-side wrangling of internal UTCTime values to ZonedTime before we export them via the OpenAPI API.

from openapi3.

Assuming the PR is as simple as I'm imagining, I'll try to find the time soon, yes.

I didn't consider UNIX timestamps. We want to store YYYY-MM-DD and HH:MM:SS uniformly on the server side as UTC and then use the client's browser to render those dates+times as appropriate for the client's locale. There's a straightforward way (or should be, per my argument above) to go from UTCTime in Haskell to date-time in OpenAPI, and then to Date in JavaScript, so what could be more convenient than that for our purposes? :)

I'm all ears though if you think there's a better/simpler way to achieve this with UNIX timestamps.

from openapi3.

I think it's a matter of personal preference. For me timestamps are better, but it may not suit you.

We always expose datetime in our API as an integer — UNIX timestamp (or timestamp*1000 for millisecond precision), which by definition is always in UTC. It's then the client's (e.g. JS application in browser) responsibility to display it in any format and in any timezone. IMO there is no possibility to parse such date wrongly. And, for me, number (UTCTime) -> string (haskell) -> string (client) -> number (Date in js) roundtrip is weird — what do we need the intermediate string for?

from openapi3.