Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Datetime support, implementing issue #86 #89
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.