Open Stack

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:
> 
>   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 the API after considering any 
>      compatibility considerations
> 
>   3) We should unify on a single format in the v3 API - IMHO, we should 
>      be explicit about use of the UTC timezone and we should avoid 
>      including microseconds unless there's a clear use case. In other 
>      words, we should use the 'isotime' format.
> 
>   4) The 'xmltime' format is just a dumb historical mistake and since 
>      XML support is now firmly out of favor, let's not waste time 
>      improving the timestamp situation in XML.
> 
>   5) We should at least consider moving to a single format in the v2 
>      (JSON) API. IMHO, moving from strtime to isotime for fields like 
>      created_at and updated_at would be highly unlikely to cause any 
>      real issues for API users.

Having dealt with timestamp issues in several other (Python) projects
I've come to the following conclusions:

* datetime values are always stored and transferred in UTC.

* UTC time values are only converted to local time for presentation
purposes.

* time zone info should be explicit (no guessing), therefore all
datetime objects should be "aware" not "naive" and when rendered in
string representation must include the tz offset (not a time zone name,
however, Z for UTC is acceptable).

* sub-second resolution is often useful and should be supported, but is
not mandatory.


-- 
John