openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #16575
One potential issue on the normalize_time() in timeutils
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
Follow ups