On 04/29/2014 09:48 AM, Mark McLoughlin wrote:
> What appeared to be unusual was that the timestamp had both sub-second
> time resolution and timezone information. It was felt that this wasn't a
> valid timestamp format and then some debate about how to 'fix' it:
> My conclusions from all that:
>
On Tue, 2014-04-29 at 10:39 -0400, Doug Hellmann wrote:
> On Tue, Apr 29, 2014 at 9:48 AM, Mark McLoughlin wrote:
> > Hey
> >
> > In this patch:
> >
> > https://review.openstack.org/83681
> >
> > by Ghanshyam Mann, we encountered an unusual situation where a timestamp
> > in the returned XML loo
On Tue, Apr 29, 2014 at 9:48 AM, Mark McLoughlin wrote:
> Hey
>
> In this patch:
>
> https://review.openstack.org/83681
>
> by Ghanshyam Mann, we encountered an unusual situation where a timestamp
> in the returned XML looked like this:
>
> 2014-04-08 09:00:14.399708+00:00
>
> What appeared to
On Tue, 2014-04-29 at 14:48 +0100, Mark McLoughlin wrote:
> My conclusions from all that:
>
> 1) This sucks
>
> 2) At the very least, we should be clear in our API samples tests
> which of the three formats we expect - we should only change the
> format used in a given part of th
Hey
In this patch:
https://review.openstack.org/83681
by Ghanshyam Mann, we encountered an unusual situation where a timestamp
in the returned XML looked like this:
2014-04-08 09:00:14.399708+00:00
What appeared to be unusual was that the timestamp had both sub-second
time resolution and t
