4 ms·
They should do the world a favor and include a datetime type.
by roncohen 13y ago
They should do the world a favor and include a datetime type.
- MichaelGG 13y agoThey have a tag for date strings, or you can use seconds from epoch, as an integer _or floating-point_. So if you actually want to represent time with proper fractional seconds, you're stuck representing them as strings. Hardly concise.
- samatman 13y agoIndeed, this is a known terrible mistake, easily avoided. The lack of the string "UUID" in the RFC is also cause for concern.
- jessaustin 13y agoAmen! How is this not an obvious step by this point?
- Someone 13y agoWhats terribly wrong with http://tools.ietf.org/html/rfc7049#section-2.4.1 http://tools.ietf.org/html/rfc7049#section-2.4.1?
- drdaeman 13y agoThe minor issues are missing timezone and precision information. But, most importantly, use of integers for datetime values hides type-level semantics. It's just integers and you, the end user, and not the deserializer, is responsible for handling the types. I think it's quite inconvenient to do tons of `data["since"] = parse_datetime(data["since"])` all the time, for every model out there.
- Someone 13y agoBut they also allow strings with time zone information: "Tag value 0 is for date/time strings that follow the standard format described in [RFC3339], as refined by Section 3.3 of [RFC4287]." RFC4287: "A Date construct is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset."