On Tue, Mar 20, 2012 at 11:03:40AM +0000, Steven Hardy wrote: > Hi All, > > I've been testing some spacewalk-clone-by-date patches on both satellite > (5.4.1) and spacewalk (nightly, postgresql), and I noticed the following on > spacewalk: > > [root@fedora_satellite utils]# ./spacewalk-clone-by-date --to_date 2007-03-03 > -u rhn-admin -l rhel-x86_64-server-5 zzerrtest2 > Password: > Reading repository information. > SHDEBUG issue_date = 2010-06-22 05:00:00+01:00 (<type 'datetime.datetime'>) : > to_date = 2007-03-03 00:00:00 (<type 'datetime.datetime'>) > Traceback (most recent call last): > File "./spacewalk-clone-by-date", line 231, in <module> > sys.exit(abs(main() or 0)) > File "./spacewalk-clone-by-date", line 221, in main > return cloneByDate.main(args) > File "/root/spacewalk/utils/cloneByDate.py", line 158, in main > tree_cloner.prepare() > File "/root/spacewalk/utils/cloneByDate.py", line 297, in prepare > cloner.prepare() > File "/root/spacewalk/utils/cloneByDate.py", line 422, in prepare > self.errata_to_clone, self.available_errata = self.get_errata() > File "/root/spacewalk/utils/cloneByDate.py", line 507, in get_errata > if err['issue_date'] <= self.to_date: > TypeError: can't compare offset-naive and offset-aware datetimes > > As you can see, there is a mismatch between the API-provided issue_date > (which is offset-aware), and the script internal to_date (which is not) > > 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. > - 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. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
