<div dir="ltr">Hi Monty,<div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 5, 2017 at 6:05 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 06/21/2017 11:13 PM, Joe Topjian wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Hello,<br>
<br>
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 :)<br>
</blockquote>
<br></span>
\o/ (sorry for the delay - somehow this list got filtered wrong. DOH)<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I was wondering if someone could provide some information as to how time is handled in OpenStack.<br>
<br>
Nova, Neutron, and Glance all seem to represent time in the following format:<br>
<br>
"updated_at": "2017-05-17T22:59:18Z"<br>
<br>
This looks to be a standard ISO8601 UTC format.<br>
</blockquote>
<br></span>
Yes. Although it should be noted that one cannot SEND full ISO8601 compliant strings - they may only be the above UTC format with no offset listed.<br>
<br>
<a href="https://github.com/openstack-infra/shade/blob/95e444f257b7f0be982616292475a6e4aaed0fe0/shade/operatorcloud.py#L2122-L2183" rel="noreferrer" target="_blank">https://github.com/openstack-i<wbr>nfra/shade/blob/95e444f257b7f0<wbr>be982616292475a6e4aaed0fe0/<wbr>shade/operatorcloud.py#L2122-<wbr>L2183</a></blockquote><div><br></div><div>Thanks - this is good to know!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
On the other hand, Cinder and Designate have the following format:<br>
<br>
"created_at": "2017-02-28T16:58:09.000000"<br>
<br>
In Gophercloud, the above format is titled RFC3339MilliNoZ:<br>
<br>
<a href="https://github.com/gophercloud/gophercloud/blob/d5eda9707e146108e4d424062b602fd97a71c2e6/results.go#L224-L242" rel="noreferrer" target="_blank">https://github.com/gophercloud<wbr>/gophercloud/blob/d5eda9707e14<wbr>6108e4d424062b602fd97a71c2e6/<wbr>results.go#L224-L242</a><br>
<br>
I'll also note that the created_at and updated_at fields in the API reference for Cinder have the date format as ISO8601:<br>
<br>
<a href="https://developer.openstack.org/api-ref/block-storage/v3/?expanded=show-a-volume-s-details-detail#show-a-volume-s-details" rel="noreferrer" target="_blank">https://developer.openstack.or<wbr>g/api-ref/block-storage/v3/?ex<wbr>panded=show-a-volume-s-details<wbr>-detail#show-a-volume-s-<wbr>details</a><br>
<br>
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<br>
</blockquote></span>
Wikipedia says: (I can't afford to buy the actual ISO spec) "Decimal fractions may be added to any of the three time elements. However, a fraction may only be added to the lowest order time element in the representation."<br>
<br>
<a href="https://en.wikipedia.org/wiki/ISO_8601" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>ISO_8601</a><br>
<br>
The trailing Z is also optional. If it's not there, the time is supposed to be assumed to be in "local time". Now - I'm pretty sure that makes NO sense in this context - so although it's a 'correct' iso8601, I'm pretty sure it's communicating something incorrect - or incomplete.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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:<br>
<br>
<a href="https://github.com/gophercloud/gophercloud/issues/248" rel="noreferrer" target="_blank">https://github.com/gophercloud<wbr>/gophercloud/issues/248</a><br>
<br>
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).<br>
<br>
But that user is able to use OSC on their API service and it works just fine.<br>
</blockquote>
><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
So it seems the Python SDK/client is being lenient on the date format. Is that accurate? If so, why?<br>
</blockquote>
<br></span>
The iso8601 python module parses both just fine:<br>
<br>
>>> iso8601.iso8601.parse_date("20<wbr>17-05-17T22:59:18Z")<br>
datetime.datetime(2017, 5, 17, 22, 59, 18, tzinfo=<iso8601.Utc>)<br>
>>> iso8601.iso8601.parse_date("20<wbr>17-02-28T16:58:09.000000")<br>
datetime.datetime(2017, 2, 28, 16, 58, 9, tzinfo=<iso8601.Utc>)<br>
<br>
and as mentioned above, it's technically valid iso8601 - concerns about the lack of Z communicating something very weird notwithstanding.<br>
<br>
I would argue with the cioa person that if they have a service that has "implemented a subset of the cinder api" and that service is returning a different format timestamp than cinder, that they have not, in fact, implemented a subset of the cinder API. OpenStack isn't an API spec - it's an implementation. So cinder's behavior IS the de-facto correct behavior.<br>
<br>
But that's not helpful - I think you'll be better off making sure you can parse either format as input. </blockquote><div><br></div><div>I see the merits of this, as well as parsing any iso8601 format in general for fields that are designed to be iso8601. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I would also not count on the data from cinder _always_ being in RFC3339MilliNoZ. The intent, AIUI, is for cinder to return iso8601 - which is remarkably lenient. :)</blockquote><div><br></div><div><div>I looked over all of this again. You're right about iso8601 being lenient -- it covers a wide range of formats. Go does not have a standard time parser like python's iso8601 module, which is unfortunate.</div><div><br></div><div>It does have some RFC3339 constants (<a href="https://golang.org/pkg/time/#pkg-constants">https://golang.org/pkg/time/#pkg-constants</a>), and I think that's where some confusion has crept in. RFC3339 requires some type of time zone notation.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote>
<br></span>
Yah. Agree. So far I'm not aware of any date/time formats that are not parseable by the python8601 module. The two you've mentioned here are the two most common forms I've seen.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Sorry for the delay responding.<br></blockquote><div><br></div><div>No problem at all - thanks for the info!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Monty<br>
<br>
______________________________<wbr>_________________<br>
Openstack-api-consumers mailing list<br>
<a href="mailto:Openstack-api-consumers@lists.openstack.org" target="_blank">Openstack-api-consumers@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-api-consumers" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-api-consumers</a><br>
</blockquote></div><br></div></div></div>