Open hachreak opened 6 years ago
we can encode datetimes automatically because there's no ambiguity (as we don't in general encode tuples) but we can't decode automatically because there's no way to know if a value is a datetime or a string. the best place to handle this is after parsing probably, where you parse keys known to be datetimes into the erlang format
I think a simple heuristic could work here. Does the string start with a number and end with a Z
, then try to decode.
Another thing which would be nice that not so much precision is lost when encoding a time-tuple. It is now translated to a second precision iso-8601 string. It would be nice if the microsecond part was also added. When during decoding that microsecond part is available it would be possible to decode back to an erlang timestamp.
Would you be interested in a PR for that?
Implemented the conversion in our jsxrecord
library which is also able to map json objects to erlang records.
I believe this issue can be closed.
Yes
Hi @talentdeficit , today when we try to
jsx:decode(jsx:encode(#{a=> erlang:timestamp()})).
we receive as result:[{<<"a">>,<<"2017-12-18T19:40:07Z">>}]
. That's because jsx recognize in encoding phase that timestamp should be translated in a datetime in TZ format. I'm wondering if in the decoding phase we could also add something to translate datetime in TZ format in erlang timestamp? Could you helping me to know where is the best point to check decoded strings and translate them if they are date? Maybe I can help you. Thanks :D