Conversation
A new boolean option, `handle_datetime`, activates the serialization and deserialization of Python datetime, date and time instances, using their standard ``isoformat()`` method. Only `naive` instances are supported, both from the pure Python implementation and from the C speedups.
The whole function is surrounded by a ``#if PY_MAJOR_VERSION < 3`` so there is no point keeping ``#if (PY_MAJOR_VERSION >= 3`` blocks in its code.
Also, recognize also a space as separator between the date and the time, for consistency with the C implementation.
* rename the flag to activate the new behaviour from "handle_datetime" to a more clear "iso_datetime" * serialize datetimes and times with an ending "Z" to make it explicit that they are naive values; the parser does recognize either forms though Correct also the Python 3 variant of the C speedups to properly handle the different FSR internal representations.
|
I'm afraid I do not understand the first comment about "local time": only naive datetime are exported, and by definition those are without a timezone... that sample output is just that, what does it make you think it's not UTC? On the other comments, well, given the reactions this feature raised, I'm leading toward making my own fork, because it's actually the loading part that's the most interesting for me, the one that written in Python is rather slow. Since both ways are opt-in, I do not understand why one should have one or the other, but not both. If you don't specify "iso_datetime" on dumps(), nothing new happens. If you don't specify "iso_datetime" on loads(), nothing new happens neither. |
|
Naive datetime should be assumed to be in the local timezone, which should be converted to UTC before serialization. It makes me think that it's not UTC because the roundtrip on that test should fail in any environment that isn't set to UTC. Looking at other parts of the code, it looks like this kind of incorrect assumption lies elsewhere. The trailing 'Z' means UTC, not naive timestamp. It's shorthand for "-00:00" or "+00:00". http://www.w3.org/TR/NOTE-datetime Having your own fork is fine, I'm not likely to accept any patch that adds parsing support for datetime in this manner, and it's not something you can reasonably implement (in the parse phase) without modifying the library. I'll go ahead and close this. |
|
Ok, thanks anyway for taking time to review. |
2 participants
I think I'm done: all tests pass on Python 2.6, 2.7 and 3.3.