Open Stack

On Fri, Jul 7, 2017 at 7:42 AM, Monty Taylor <mordred at inaugust.com> wrote:

Maybe we can convince someone to write a go iso8601 library. (I know I
> certainly don't want to write a date/time parsing library myself- that's a
> road to madness! :) )
>

I would have so much respect for the person/team who took that on :)

Go provides a way to parse a date from a given template (kind of like a
reverse strftime), but no way to parse an arbitrary string as a date.

To exaggerate just for discussion sake, let's say a full blown iso8601
parsing library is overkill just to be able to parse a date from the
various OpenStack services. If all OpenStack services sent the same format,
Go's built-in parsing template would work just fine.

Out of genuine curiosity:

1. Why don't the services all send back the same date format? It feels like
an innocent oversight and assumption that the client SDK will be able to
handle the date easily.

2. What would it take (and how many years) for all services to conform to
the same format?

Now I'm kind of playing Devil's Advocate here. I understand that saying
things like "consistency" and "all OpenStack services" have a lot of valid
debates behind them. But from the point of view of someone consuming
"OpenStack" and finding inconsistencies like this, it's both frustrating
and confusing.

At a minimum, would it make sense to update the API reference docs to more
accurately reflect the actual date format returned for each service?

3. As a general API design question (which I have no experience or
knowledge of), isn't saying a timestamp field that's in iso8601 format just
as ambiguous as saying a "status" field is a string (which could
technically be a limited set / enumerable)? Couldn't the API spec be more
specific to the exact format that should be returned to at least provide a
decisive reference?

Again, exaggerating, the following is valid iso8601 timestamp:

20170709T134503Z

Short of the question about updating the docs, the other questions are more
out of curiosity with no actions implied :)

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