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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
