[openstack-dev] [Oslo] jsonutils support for datetimes
Dolph Mathews
dolph.mathews at gmail.com
Mon Jun 3 13:01:46 UTC 2013
-Dolph
On Mon, Jun 3, 2013 at 6:33 AM, Flavio Percoco <flavio at redhat.com> wrote:
> Hi,
>
> I'm planning to re-factor current Oslo's jsonutils module and as part
> of that re-factor process I'd like to add a better support for datetimes
> objects.
>
> Before going further with the implementation, I'd like to get some
> feedback from folks and see if any of you have already done it or at
> least thought about it.
>
> Currently jsonutils serializes datetimes using timeutils.strtime
> function, which returns a ISO8601 formatted string. Since this is a
> string, there's no easy way to understand, when de-serializing,
> whether it is a datetime, was a datetime before and / or should be
> de-serialized as datetime.
>
> The first point is:
>
> 1) Do we really need this?
> From a "compatibiliy" POV I'd prefer not having it and avoid
> sending datetimes that are supposed to be de-serialized. However,
> there are definitely cases were this is useful and makes
> implementations way easier.
>
> 2) Does it make sense to have this in Oslo?
>
> My bet is yes. We currently need it in Glance and I think other
> projects can benefit from this - nova does something similar. (We
> can use Glance as a POC for this).
>
keystone could definitely use this, as long as it can handle ISO 8601
extended time formats w/ microseconds, e.g. "2013-02-27T16:30:59.999999Z"
>
>
> 3) I've put some thoughts on it that I'd like to share:
>
> 1) Try always to convert the str to datetime - using
> timeutils.parse_strtime. The drawback is that we might convert to
> datetimes values that weren't datetime before being serialized.
> Similar to what nova's sqlalchemy api does[0].
>
> 2) Add a prefix / suffix to the serialized datetime. This will
> allow the de-serializer to know whether it should be converted to
> datetime.
>
If this happens automatically, won't it just break existing clients?
>
> 3) Serialize the datetime as a dictionary with the following
> structure:
>
> {"_type": "datetime", "_value": "....",
> "_format": "%Y-%m-%dT%H:%M:%S.%f"}
> The above will allow the de-serializer to know whether it
> should be converted, the object type (datetime, date or time)
> and the format it was serialized with. I don't like this idea
> but I see the benefit of having all that information.
>
Agree with the hesitation.
>
>
> [0]
> https://github.com/openstack/**nova/blob/master/nova/db/**
> sqlalchemy/api.py#L276<https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L276>
>
> Any thoughts / ideas?
>
> Cheers,
> FF
>
> --
> @flaper87
> Flavio Percoco
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130603/7cc06a45/attachment.html>
More information about the OpenStack-dev
mailing list