<br><br><div class="gmail_quote">On Fri, Nov 2, 2012 at 11:57 AM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
> > Looking over <a href="https://bugs.launchpad.net/ceilometer/+bug/1048647" target="_blank">https://bugs.launchpad.net/ceilometer/+bug/1048647</a>,<br>
> > we'd<br>
> > like some feedback on timezone aware datetimes for the timestamp<br>
> > fields (in Meters and Resources tables).  From what I understand,<br>
> > some<br>
> > backends do not support timezone in timestamp type fields , such as<br>
> > MongoDB and Postgres.  I think the way Nova handles it is that it<br>
> > expects all timestamps in the database is expected to be UTC.<br>
><br>
> Postgres actually has separate types for timestamp without time zone<br>
> and<br>
> timestamp with time zone.<br>
><br>
> But I think it makes a lot more sense to just use UTC timestamps<br>
> everywhere, rather than using timezone-aware timestamps which will<br>
> involve more database-specific code.  If you care about the user's<br>
> timezone, you can put it in a separate column.<br>
<br>
</div>Totally agree about standardizing on UTC ... having lived with<br>
systems using TZ-specific timestamps, its a never-ending saga of<br>
confusion & pain.<br></blockquote><div><br></div><div>It looks like there's a strong consensus on using UTC without a TZ in the datetime object. We should go ahead and make any changes needed to do that, then document our expectations in our public documentation for the API and in the storage driver API specification (maybe in the storage driver base class method for storing new metering data?).</div>
<div><br></div><div>Doug</div><div><br></div></div>