[Openstack-api-consumers] Time Formats

Joe Topjian joe at topjian.net
Thu Jun 22 04:13:39 UTC 2017


Hello,

I'm Joe and I do a lot of work with OpenStack and Go. Since Go is a rather
strict language, it's easy to run into inconsistencies both between
different OpenStack services as well as what the OpenStack API docs
mention. So some of the things I'll be posting here are to ask for
clarification on such findings :)

I was wondering if someone could provide some information as to how time is
handled in OpenStack.

Nova, Neutron, and Glance all seem to represent time in the following
format:

"updated_at": "2017-05-17T22:59:18Z"

This looks to be a standard ISO8601 UTC format.

On the other hand, Cinder and Designate have the following format:

"created_at": "2017-02-28T16:58:09.000000"

In Gophercloud, the above format is titled RFC3339MilliNoZ:

https://github.com/gophercloud/gophercloud/blob/d5eda9707e146108e4d424062b602fd97a71c2e6/results.go#L224-L242

I'll also note that the created_at and updated_at fields in the API
reference for Cinder have the date format as ISO8601:

https://developer.openstack.org/api-ref/block-storage/v3/?expanded=show-a-volume-s-details-detail#show-a-volume-s-details

Unless I'm mistaken, and I am not an expert on time standards, that's not
correct? Someone has even mentioned that the lack of Z or any time zone
notation is invalid ISO8601 to begin with.

Having different formats isn't a *huge* deal. A note can be filed and the
different formats per service can be managed. Where this gets interesting
is in the following discussion:

https://github.com/gophercloud/gophercloud/issues/248

tl;dr: Someone has written a Block Storage compatible API service. This
service is returning dates in the ISO8601 format. Gophercloud is giving an
error because it is expecting the date format to be in that milli-no-z
format like in the "official" Block Storage service (Cinder).

But that user is able to use OSC on their API service and it works just
fine.

So it seems the Python SDK/client is being lenient on the date format. Is
that accurate? If so, why?

As well, what time formats should be officially and confidently supported
across all services? I'm not the kind of person who gets hung up on
specifics, but having to add support for multiple formats just in case one
of those is returned feels a little disorganized.

Thanks,
Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-api-consumers/attachments/20170621/f181da2d/attachment.html>


More information about the Openstack-api-consumers mailing list