can't serialize datetime.datetime

[llonchj]

TypeError: "can't serialize datetime.datetime"

import datetime
import msgpack
msg = msgpack.packb(datetime.datetime.now())

[methane]

Please see http://docs.python.org/library/json.html#json.dump

In [1]: import msgpack, json, datetime

In [2]: msgpack.packb(datetime.datetime.now())
TypeError: can't serialize datetime.datetime(2012, 8, 22, 21, 38, 49, 86870)

In [3]: json.dumps(datetime.datetime.now())
TypeError: datetime.datetime(2012, 8, 22, 21, 39, 1, 23217) is not JSON
serializable

In [4]: json.dumps(datetime.datetime.now(), default=str)
Out[4]: '"2012-08-22 21:39:52.382590"'

In [5]: msgpack.dumps(datetime.datetime.now(), default=str)
Out[5]: '\xba2012-08-22 21:39:57.446722'

On Wed, Aug 22, 2012 at 9:25 PM, Jordi Llonch notifications@github.comwrote:

TypeError: "can't serialize datetime.datetime"

import datetime
import msgpack
msg = msgpack.packb(datetime.datetime.now())

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12.

INADA Naoki songofacandy@gmail.com

[tmehlinger]

Though there's no standard for date/time representation in JSON, there's a strong push to standardize on ISO 8601.
Javascript's Date().toJSON() behavior is, nearly universally, to return an ISO 8601 timestamp. An overwhelming number of libraries and services that use JSON for interchange assume ISO 8601 for date/time representation. I think it's safe to assume you can serialize datetime objects with .isoformat() by default instead of forcing the developer to provide a default function.

[methane]

DateTime object and it's string representation is different thing.
I don't like making default behavior more lossy.

I welcome proposal of more easy and efficient way to customize (de)serialization.

[tmehlinger]

Using .isoformat() as the default behavior wouldn't be lossy. ISO 8601 represents all the information available in a datetime.

[methane]

It loses type information.

[HoverHell]

What about extending msgpack format for datetime and decimal (and, possibly, something else)? (were there already discussions on this point?)
Or it would be preferable to add those customizations locally instead of main msgpack format (assuming messages are only used internally)?

proposal of more easy and efficient way to customize (de)serialization

A default-like function that returns packed data (instead of just serializable data)? Though in practical use that would mean extending the format as well. Best I can see (probably not very good) is adding “custom format” type to msgpack with (custom_format_id, length, data_string) packed internals (with corresponding custom functions for (de)serializing).

[alekibango]

Timestamp related discussion is also here msgpack/msgpack#128

[wbolster]

If you want to keep your msgpack values really compact, temporenc (http://temporenc.org), a comprehensive binary encoding format for dates and times, might be what you're looking for. ;)