<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 7, 2017 at 7:42 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:</div><div class="gmail_quote"><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">
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! :) )<br></blockquote><div><br></div><div>I would have so much respect for the person/team who took that on :)</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Out of genuine curiosity:</div><div><br></div><div>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.</div><div><br></div><div>2. What would it take (and how many years) for all services to conform to the same format?</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>Again, exaggerating, the following is valid iso8601 timestamp:</div><div><br></div><div>20170709T134503Z<br></div><div><br></div><div>Short of the question about updating the docs, the other questions are more out of curiosity with no actions implied :)</div><div><br></div><div>Thanks,</div><div>Joe</div></div></div></div>