I've grown used to the date/time types provided by NodaTime/JodaTime/Java 
8: 

Instant - point on the global timeline, no calendaring implied, serialized 
"2017-06-02T18:10:15.254Z"
LocalDate - A date, serialized "2017-06-02" (analagous to the current date 
type in swagger)
LocalTime - A time of day, serialized "11:10:15.254"
LocalDateTime - A combination of LocalDate and LocalTime, serialized 
"2017-06-02T11:10:15.254"
OffsetDateTime - A date and time with offset (analagous to the current 
dateTime type in swagger), serialized "2017-06-02T11:10:15.254-07:00"
ZonedDateTime - A date and time with a specific time zone. This is more 
handy than an OffsetDateTime because you can add a duration to it, and get 
a correct answer about what the new local time is. If you only have an 
offset you don't know when the offset is supposed to change. Though the 
serialization for this is a bit trickier since ISO 8601 doesn't discuss 
time zones. But it might be something like this for a TZDB time zone: 
"2017-06-02T11:10:15.254 America/Los_Angeles (-07)"

I find that specifying one of the types is really helpful to avoid bugs, 
like treating a UTC date as local, or mis-handling a Daylight Savings 
switch where you get duplicate times or gaps in the timeline, or where an 
event now fires 1 hour off where it should. I've seen a lot of these, and 
they could have all been avoided by using the right types. I think it would 
be helpful to be able to express the date accurately via an API to increase 
clarity and reduce the chances that a date is mis-used.

Since the built-in primitive types don't support these, what options do I 
have to add these to an API defined by Swagger? I see that the "format" 
field is free-form, so I could put my own strings in there, but it seems 
like an incomplete solution, as the standard codegen would just treat these 
as strings. It seems like having some new types to support these would be 
the best, then updating to codegenerators to handle them. Libraries with 
incomplete coverage like .NET or pre-8 Java would have everything fall back 
to the generic type (Date for Java and DateTimeOffset for .NET), while 
libraries like JodaTime, Java 8 and NodaTime could map directly. Though, I 
don't know if another specification version is in the cards or not.

Does this make sense? Where would be the best place to put this support?

-- 
You received this message because you are subscribed to the Google Groups 
"Swagger" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to