-
Notifications
You must be signed in to change notification settings - Fork 19
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
Add [proposed] rfc3339 zoned date time #77
base: main
Are you sure you want to change the base?
Conversation
I wasn't expecting any special code for the RFC 3339 extension to be in the serializers code. I was expecting to write:
Does that make sense? |
This isn't ready yet, but working on it highlighted a couple issues that I'm wondering how to deal with:
I instead went for the accepting a fully formed converter over just the pattern. Thoughts on that? |
sorry; you beat me to the punch; the reason i posted this as draft was to get a better understanding. so you'd prefer, to add a pattern to the main repo and the then the replacement converter here. that's fine. what do you think about the calendar issue and also the replacment converter vs replacment pattern issue? |
and of course, any other comments :) no hurry; i just figured I'd bang something out while it was on my mind and i had a little time. |
I'll try to have a closer look tomorrow for those questions. |
In terms of pattern/converter: I think it might make sense to have both. It's slightly frustrating that we need the calendar validator so we can't really just have the one accepting a pattern, although I think that would be useful sometimes. But given that the converter code isn't specific to Noda Time, we could probably call that just In terms of the calendar and other parameters: I'd suggest that our initial pattern, exposed as |
Thanks for the guidance, Jon. This makes sense. On the calendar parameter, if I understand, that means the pattern will fail if passed |
I would suggest something like "plain" rather than "without calendar" - it won't support any parameters, whether they're |
It does seem like at some point, if the RFC3339 extension is approved as written, you'll want an optional calendar pattern, e.g. |
My guess is that in reality, the number of people who use it with a calendar parameter will be small. We'll see :) |
PR to address #76 by adding support for the proposed RFC 3339 extension to date time formats to allow serializing of time zone.
This would allow using a serialization format that is consistent with java and the pending Temporal proposal to ECMA/javascript