-
-
Notifications
You must be signed in to change notification settings - Fork 158
Add support for DateOnly/TimeOnly #1169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1169 +/- ##
==========================================
+ Coverage 92.63% 92.69% +0.05%
==========================================
Files 243 243
Lines 7806 7815 +9
==========================================
+ Hits 7231 7244 +13
+ Misses 575 571 -4
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Converted back to Draft because this hasn't been tested with ModelState validation, so may not work. |
Turns out this isn't going to work well with ModelState validation on .NET 6, because
Update: There's a polyfill NuGet package now, to fill the gap for .NET 6. |
b7184fd
to
78d753c
Compare
… backwards-compatibility)
This PR adds support for using DateOnly and TimeOnly in resource models, which were introduced in .NET 6.
PostgreSQL fully supports these types. But unfortunately, System.Text.Json support and ModelState binding support for these types are missing in .NET 6. They were added in .NET 7. To use these types in .NET 6:
builder.Services.AddDateOnlyTimeOnlyStringConverters();
at startup.While implementing this, I found that query string parsing uses the OS-level culture settings. For example, if you're running your API on an English language version of Windows, but have customized regional settings to display dates in Dutch format, then you'll need to use Dutch notation for date values in query strings (for example
31-12-2022
instead of12/31/2022
). This doesn't apply to JSON request/response bodies, so the behavior is quite inconsistent. This PR fixes that by always using the Invariant culture. A backward-compatibility switch has been added, so we don't need to wait for the next major release. To revert to the old behavior, add the following at startup:Fixes #1168.
NOTE: This PR depends on #1249 and #1253, which should be merged first.QUALITY CHECKLIST