Add support for date/time formats

[durandj]

DRAFT PR

This is a draft of the final product. So far I've implemented 2 of the 3 date/time formats and wanted to confirm that my approach was acceptable before doing the third and before updating the docs.

I also want to add some helper functions for my custom type I had to add which you can learn more about below.

Summary

This PR adds support for the 3 date/time formats that are supported by JSON schema: date, time, and date-time.

All 3 formats build off of the time.Time type but in a couple different ways. For date-time we can just use the native type because the provided behavior for JSON is exactly what is desired. When marshaling to JSON the value is converted to an ISO-8601 timestamp. When unmarshaling from a JSON string it expects an ISO-8601 timestamp.

For date and time though things had to be changed up a bit. With date we expect to only be given a date string without any time component and the time format is the same but in reverse. If you tried to unmarshal \"2023-01-02\" though you would get an error since it's missing a time component.

There were 5 possible approaches that I came up with to resolve this issue:

1. Create a shim type for each string that is marked as a date or a time which knows how to properly marshal/unmarshal the value. I rejected this approach because it could create a lot of extra bloat in the client code if there are a lot of generated types. It is however the most straightforward approach.
2. Modify the UnmarshalJSON and MarshalJSON methods that are generated to be aware of if there's a date or time field and if so write to a map and then iterate over each field and do custom logic for each field. This gives the most flexibility but is overly complicated and basically re-implements what Go does so I rejected this approach.
3. Create a shim of the entire generated code which treats all date and time fields as strings and then generates a final type which has time.Time as the field value. There would then need to be extra logic to initially use the shim type and then convert to the final type and do special handling for dates and times. This again produces a lot of boilerplate and requires create two copies of the data which seems wasteful so this was rejected.
4. Don't do anything special and just leave date and time values as strings but this is annoying as a consumer of this tool since I have to do the conversion myself so this was rejected.
5. Create a thin wrapper around the time.Time type which knows how to handle the missing component (the time for date and the date for time). This type can be used basically the same as a time.Time instance (because that's what it is) but it will work with JSON in a cleaner way. I'm not super thrilled that this adds a new type that must be interacted with in client code but there are some examples of this in the Go standard library already ( https://pkg.go.dev/database/sql#NullBool )

On top of adding tests for these changes into this repository I also tested them against my own project where I wanted to use this tool.

[omissis]

Hey @durandj , thanks for the contribution! I will look at it asap :)

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (8e9be7c) 0.00% compared to head (0fae179) 77.99%.

Additional details and impacted files

@@            Coverage Diff            @@
##           main      #98       +/-   ##
=========================================
+ Coverage      0   77.99%   +77.99%     
=========================================
  Files         0       17       +17     
  Lines         0     1718     +1718     
=========================================
+ Hits          0     1340     +1340     
- Misses        0      293      +293     
- Partials      0       85       +85     

Files	Coverage Δ
pkg/codegen/utils.go	92.30% <100.00%> (ø)
types/date.go	100.00% <100.00%> (ø)
types/time.go	100.00% <100.00%> (ø)

... and 14 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[omissis]

hey @durandj ! I've been looking at your proposal it looks solid to me, so +1 for going down that path. I've also took a moment to look around this issue on the Go repository and pondered if we could use google's civil package, but it's probably better to provide our types instead of requiring a third party library.

[durandj]

Huh interesting, hadn't seen the civil package before. Yeah I'm thinking it's better to stick to the one required dependency for consumers versus opting them into another without consent.

Cool, if you're happy with how this looks so far then I'll work on getting the time format completed as well and then get the docs updated as well.

Thanks for the preliminary review!

[omissis]

hi @durandj ! did you have any time to work on this PR? do you need some help? I'd love to merge it in a future release :)

[durandj]

Hey @omissis, sorry for the delay. Things have been busy so I haven't had much time to work on this. Things should be all set for review now though.

[omissis]

hey hey! no problem at all, no worries :) I'll review in the next few days, thanks again! 💪