fix(prost-types): Allow unknown local time offset #1109
Conversation
`chrono` allows a negative zero local offset. I think we should follow their example. The RFC 3339 spec says this is a special value, but doesn't specify how to handle the situation. https://www.rfc-editor.org/rfc/rfc3339#section-4.3
|
@mumbleskates I found another difference with chrono. Do you agree that following chrono parsing is the way to go? |
|
I'm less sure about this. There are quite a few total differences between prost-types and chrono, and i don't necessarily hold chrono as a gold standard, just as a known correct implementation of date-and-time math. there are other differences too: chrono also accepts years with different numbers of digits, and represents leap seconds by letting nanos overflow rather than doing anything else. looking at the standards, it seems that -00:00 does indeed represent "unknown local offset" in rfc3339, and is outright forbidden in iso8601. in this sense (as well as handling unsigned year numbers with other than four digits) i think prost-types seems more correct than chrono, and these cases could easily merit exceptions in the fuzzer rather than adaptation by the library. |
|
welllllll.... it is true that "unknown local offset" in rfc3339 does say that the UTC time is known here. Which does mean that we can use the time; it's equivalent to Zulu, we just don't know what the end user wants for humanized time... but we aren't actually attempting to represent the time zone, we're throwing it away regardless. Maybe this change is completely fine |
2 participants
chronoallows a negative zero local offset. I think we should follow their example.The RFC 3339 spec says this is a special value, but doesn't specify how to handle the situation. https://www.rfc-editor.org/rfc/rfc3339#section-4.3