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 <daveshawley@gmail.com> wrote:
On Nov 3, 2018, at 9:29 AM, Chris Angelico <rosuav@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