So it looks like all dates returned by cinder are UTC, always. There are a couple of migrations that use date.now rather than date.utcnow that should probably be fixed, and we should add a hacking check to remove all use of date.now.
Other than that, out best bet for the V1/V2 APIs is to just document the fact it is always UTC - any change to the date format in the output is an API breakage.
If/when we do a V3 api, we can revisit - hopefully there'll be some good guidance from the API working group on the subject by then
So it looks like all dates returned by cinder are UTC, always. There are a couple of migrations that use date.now rather than date.utcnow that should probably be fixed, and we should add a hacking check to remove all use of date.now.
Other than that, out best bet for the V1/V2 APIs is to just document the fact it is always UTC - any change to the date format in the output is an API breakage.
If/when we do a V3 api, we can revisit - hopefully there'll be some good guidance from the API working group on the subject by then