[Openstack] One potential issue on the normalize_time() in timeutils

Jiang, Yunhong yunhong.jiang at intel.com
Sun Sep 9 15:09:06 UTC 2012


Hi, Eoghan and all, 

	When I implement an enhancement to trusted_filter, I need utilize timeutils() to parse ISO time. However, I suspect there is one potential issue in normalize_time() and want to get some input from your side.

	In normalize_time(), if the parameter "timestamp" is an aware object (http://docs.python.org/library/datetime.html) , it's output will vary depends on the input. If the timestamp is UTC time, it will be return as is without convention, i.e still an aware object. However, if it's not an UTC time, it will be converted to be a naive object.
	This mean that the function will return different type depends on input, that's not so good IMHO.

	The worse is, any compare/substract between naïve object and aware object will fail. Because the timeutils.utcnow() and datetime.datetime.now() returns naive object, so compare/substract between the uctnow() and normalize_time() may fail, or not, depends on input from the API user. I'm a bit surprised that changes-since works on such situation :)

	I suspect this is caused by the "if offset". When timestamp is naïve object, the offset is None. Thus check "if offset" will avoid operation type exception. However, if the timestamp is UTC time, the offset will be date.timeslot(0), which will return false also for "if offset". 

	Are there any special reason that we need keep aware object if input is at UTC time already? Can I changes the function to always return naive object? If yes, I can create a patch for it.

Thanks
--jyh




More information about the Openstack mailing list