JSONRender fails to serialize timedelta objects

[radiosilence]

It's also not immediately clear as to how to override the behaviour.

[tomchristie]

See the encoder implementation: https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/utils/encoders.py#L13

(Not documented as it's considered a private api)

[asfaltboy]

For timedelta, we can take a look at Mark Hildreth's approach:
http://taketwoprogramming.blogspot.co.il/2009/06/subclassing-jsonencoder-and-jsondecoder.html

more precisely:

elif isinstance(obj, timedelta):
            days = obj.days
            seconds = obj.seconds
            milliseconds = obj.microseconds / 1000
            milliseconds += obj.seconds * 1000
            milliseconds += obj.days * 24 * 60 * 60 * 1000

            return 'td(%d)' % (milliseconds)

[tomchristie]

I don't think that approach is quite appropriate here since it encodes into such a specific format.
I think we should simply encode timedeltas into '1234.567' strings (Note Decimals also necessarily get string representations).

NB. In the other direction there's no need for the JSON decoder to be able to determine and decode the type into a timedelta automagically, as that's a serializer concern.

[radiosilence]

I think strings would be fine, because the serializer *knows *what we're
going to be decoding to, and a timedelta is just a bunch of settings.
Should I figure out my own subclassed decoder or do you think this will be
in upstream?

James Cleveland
Web Developer
telephone? +44(0)7865 99 88 57
website? www.dapperdogstudios.com

On 9 November 2012 15:55, Tom Christie notifications@github.com wrote:

I don't think that approach is quite appropriate here since it encodes
into such a specific format.
I think we should simply encode timedeltas into '1234.567' strings (Note
Decimals also necessarily get string representations).

NB. In the other direction there's no need for the JSON decoder to be able
to determine and decode the type into a timedelta automagically, as that's
a serializer concern.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/392#issuecomment-10233971.

[radiosilence]

There's also the option of doing str(mytimedelta) which works, and to
decode you could do timedelta(*mystr.split(':')) (except not quite)

James Cleveland
Web Developer
telephone? +44(0)7865 99 88 57
website? www.dapperdogstudios.com

On 9 November 2012 15:57, James Cleveland jamescleveland@gmail.com wrote:

I think strings would be fine, because the serializer *knows *what we're
going to be decoding to, and a timedelta is just a bunch of settings.
Should I figure out my own subclassed decoder or do you think this will be
in upstream?

James Cleveland
Web Developer
telephone? +44(0)7865 99 88 57
website? www.dapperdogstudios.com

On 9 November 2012 15:55, Tom Christie notifications@github.com wrote:

I don't think that approach is quite appropriate here since it encodes
into such a specific format.
I think we should simply encode timedeltas into '1234.567' strings (Note
Decimals also necessarily get string representations).

NB. In the other direction there's no need for the JSON decoder to be
able to determine and decode the type into a timedelta automagically, as
that's a serializer concern.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/392#issuecomment-10233971.

[radiosilence]

So yeah, seconds is probably best, because I just realised that str(delta)
comes up with shit like "4 days, 12:23:32" which would be a pain to decode.

James Cleveland
Web Developer
telephone? +44(0)7865 99 88 57
website? www.dapperdogstudios.com

On 9 November 2012 15:58, James Cleveland jamescleveland@gmail.com wrote:

There's also the option of doing str(mytimedelta) which works, and to
decode you could do timedelta(*mystr.split(':')) (except not quite)

James Cleveland
Web Developer
telephone? +44(0)7865 99 88 57
website? www.dapperdogstudios.com

On 9 November 2012 15:57, James Cleveland jamescleveland@gmail.comwrote:

I think strings would be fine, because the serializer *knows *what we're
going to be decoding to, and a timedelta is just a bunch of settings.
Should I figure out my own subclassed decoder or do you think this will be
in upstream?

James Cleveland
Web Developer
telephone? +44(0)7865 99 88 57
website? www.dapperdogstudios.com

On 9 November 2012 15:55, Tom Christie notifications@github.com wrote:

I don't think that approach is quite appropriate here since it encodes
into such a specific format.
I think we should simply encode timedeltas into '1234.567' strings (Note
Decimals also necessarily get string representations).

NB. In the other direction there's no need for the JSON decoder to be
able to determine and decode the type into a timedelta automagically, as
that's a serializer concern.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/392#issuecomment-10233971.

[tomchristie]

Should I figure out my own subclassed decoder or do you think this will be
in upstream?

Into core is good.

[tomchristie]

@radiosilence

Yo. Made something for ya. ⚡ 😏 ⚡

[radiosilence]

#584 :O

[minddust]

yeah! :D
nice meme 👍