-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
encode/decode datetime #117
Comments
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 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 |
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
The text was updated successfully, but these errors were encountered: