Hi Jan, Thanks for the reply:
On Mon, May 07, 2012 at 12:54:32PM +0200, Jan Pazdziora wrote: > > Testing on satellite shows that the API provided issue_date is not offset > > aware, so the comparison works. > > > > I was going to implement a workaround in spacewalk-clone-by-date, but first > > I wanted to check: > > - Is this expected? > > No, I'd consider it a bug. Ok, thanks for the clarification - I'll try to revisit this and implement a fix. I had to stop using spacewalk-clone-by date due to bz807463 (API issue), but since that's now fixed I'll try to find time to have a another look, as I had several enhancements which I started by never finished. > > - I would think storing timestamps in the database in a non-timezone-aware > > format would be better - could this be a spacewalk/postgresql schema issue? > > With Oracle backend, we are using date -- no timezones. With > PostgreSQL, we are using timestamp with time zone. In general, data > inserted to the database are in local time zone (of the database / > server). So you are not really losing any information. > > > - If all timestamps should be offset-aware, should spacewalk-clone-by-date > > assume zero offset for to_date, or inherit from the locale? > > Use localtime from the locale, I'd say. OK, I guess that works Steve _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
