Comments (8)
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 UTCTime
s 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.
Related Issues (20)
- `encodePretty` should be exposed from `Data.OpenApi`
- Invalid schema with types with primes (`'`)
- Generic polymorphic schema handle lists differently to aeson HOT 2
- Outdated documentation re sum encoding differs ToSchema/ToJSON? HOT 1
- Wrong format when generating empty scopes map HOT 2
- Exception when parsing newer OpenApi3 schemas HOT 4
- Add `nullable` attribute HOT 4
- _OpenApiItemsArray and _OpenApiItemsObject should be Prisms, not Reviews
- invalid schema HOT 1
- Structural error at components.schemas.AggregateMRQuery.properties.select.items.items should be object HOT 2
- SecurityDefinitions missing "Index" and "IxValue" type family instances
- SecurityDefinitions missing "Ixed" and "At" type-class instances
- Allow GHC-9.6
- Mismatch between ToJSON and ToSchema with nullary single-record constructor
- How to implement allOperations for optics? HOT 2
- Hardcoded references
- add `ToSchema Schema` instance
- validateJSON semantics with `allOf` seem incorrect
- Why are the schemas different for `ToParamSchema UUID` and `ToSchema UUID`
- Prefix stripping when a `$ref` is parsed as a `Referenced` is confusing HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openapi3.