You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to upgrade the cookie crate to time 0.2. As I understand it the relevant date format specification is https://tools.ietf.org/html/rfc2616#section-3.3.1. However, the current approach of not having %Z causes a bunch of pain for parsing these dates. Specifically, parse() for OffsetDateTime seems to return InsufficientInformation if I just try to parse with "GMT" in the format. So it seems I'd have to do a dance of (a) parsing a PrimitiveDateTime, (b) calling to_offset() on it, and (c) validating that it had the "GMT" or equivalent.
I think the approach of actually having %Z support only for GMT and UTC was probably a better trade-off, especially since that would allow both a numeric offset as well as some of these abbrevations. Otherwise, perhaps OffsetDateTime could maybe provide a parse_with_offset() (or just parse_utc()) method that allows a non-numeric offset literal in the format string while using the provided offset.
The text was updated successfully, but these errors were encountered:
I'll actually be upgrading the cookie crate myself tomorrow — the time crate needs some prerequisites before moving forward with that. Sergio gave me the go-ahead earlier tonight. Just letting you know so there's no duplicated efforts 🙂
The approach I have taken in the conversion so far is to parse as a PrimitiveDateTime (using "GMT" explicitly), and then add the offset back in. Time v0.1 had its parsing handled identically to C, which is where the odd behavior came from. It did have surprising behavior in many situations, which is why I removed it. It'll be re-introduced when tzdb support is done (it's not yet started). That will go to a ZonedDateTime, as parsing offsets must be fixed (yes, UTC is, but many zones aren't).
I'm trying to upgrade the cookie crate to time 0.2. As I understand it the relevant date format specification is https://tools.ietf.org/html/rfc2616#section-3.3.1. However, the current approach of not having
%Z
causes a bunch of pain for parsing these dates. Specifically,parse()
forOffsetDateTime
seems to returnInsufficientInformation
if I just try to parse with "GMT" in the format. So it seems I'd have to do a dance of (a) parsing aPrimitiveDateTime
, (b) callingto_offset()
on it, and (c) validating that it had the "GMT" or equivalent.I think the approach of actually having
%Z
support only forGMT
andUTC
was probably a better trade-off, especially since that would allow both a numeric offset as well as some of these abbrevations. Otherwise, perhapsOffsetDateTime
could maybe provide aparse_with_offset()
(or justparse_utc()
) method that allows a non-numeric offset literal in the format string while using the provided offset.The text was updated successfully, but these errors were encountered: