jsondate, for example, supports both .load[s]() and .dump[s](); but only for UTC datetimes
https://github.com/rconradharris/jsondate/blob/master/jsondate/__init__.py UTC is only sometimes a fair assumption; otherwise it's dangerous to assume that timezone-naieve [ISO8601] strings represent UTC-0 datetimes. In that respect - aside from readability - arbitrary-precision POSIX timestamps are less error-prone. On Saturday, November 3, 2018, David Shawley <daveshaw...@gmail.com> wrote: > On Nov 3, 2018, at 9:29 AM, Chris Angelico <ros...@gmail.com> wrote: > > > I think we need to clarify an important distinction here. JSON, as a > format, does *not* support date/time objects in any way. But > JavaScript's JSON.stringify() function is happy to accept them, and > will represent them as strings. > > > Very good point. The JSON document type only supports object literals, > numbers, strings, and Boolean literals. My suggestion was specifically to > provide an extensible mechanism for encoding arbitrary objects into the > supported primitives. > > If the suggestion here is to have json.dumps(datetime.date(2018,11,4)) > to return an encoded string, either by natively supporting it, or by > having a protocol which the date object implements, that's fine and > reasonable; but json.loads(s) won't return that date object. So, yes, > it would be asymmetric. I personally don't have a problem with this > (though I also don't have any strong use-cases). Custom encoders and > decoders could do this, with or without symmetry. What would it be > like to add a couple to the json module that can handle these extra > types? > > > Completely agreed here. I've seen many attempts to support "round trip" > encode/decode in JSON libraries and it really doesn't work well unless you > go > down the path of type hinting. I believe that MongoDB uses something akin > to > hinting when it handles dates. Something like the following representation > if I recall correctly. > > { > "now": { > "$type": "JSONDate", > "value": "2018-11-03T09:52:20-0400" > } > } > > During deserialization they recognize the hint and instantiate the object > instead of parsing it. This is interesting but pretty awful for > interoperability since there isn't a standard that I'm aware of. I'm > certainly not proposing that but I did want to mention it for completeness. > > I'll try to put together a PR/branch that adds protocol support in JSON > encoder > and to datetime, date, and uuid as well. It will give us something to > point at > and discuss. > > - cheers, dave. > -- > Mathematics provides a framework for dealing precisely with notions of > "what is". > Computation provides a framework for dealing precisely with notions of > "how to". > SICP Preface >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
