On Sun, Nov 4, 2018 at 12:02 AM David Shawley <daveshaw...@gmail.com> wrote: > > On Nov 2, 2018, at 12:28 PM, Calvin Spealman <cspea...@redhat.com> wrote: > > > Second, JSON is a specific serialization format that explicitly rejects > > datetime objects in *all* the languages with JSON libraries. You can only > > use date objects in JSON if you control or understand both serialization > > and deserialization ends and have an agreed representation. > > I would hardly say that "rejects datetime objects in *all* languages..." > > Most Javascript implementations do handle dates correctly which is a bit > telling for me. For example, the Mozilla reference calls out Date as > explicitly supported [1]. I also ran it through the Javascript console and > repl.it to make sure that it wasn't a doc glitch [2].
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. 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? ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
