I'm contributing on Karbor (https://wiki.openstack.org/wiki/Karbor).
Recently, I find a bug in the following codes.
def resume_operation(self, operation_id, **kwargs):
end_time = kwargs.get('end_time_for_run')
now = datetime.utcnow()
if not isinstance(end_time, datetime) or now > end_time:
return
'end_time_for_run' comes from DB with following definition.
class ScheduledOperationState():
fields = {
'end_time_for_run': fields.DateTimeField(nullable=True),
}
when 'now' compares to 'end_time', it will raise an exception as I described
before.
I mean now that timeutils.untcnow and datetime.utcnow will return a time without
a timezone info attached by default, why not change DateTimeField to keep it
coincidence with them. I should be a good optimize in the point of view of easy
of use.
Certainly, I can change the codes as you described.
Really appreciate your reply.
Best Wishes!
zeng chen
At 2017-03-09 10:43:23, "Jay Pipes" <jaypi...@gmail.com> wrote:
>On 03/08/2017 09:07 PM, zengchen wrote:
>> Hi, jay
>> Thanks for your reply. Do you means it is no need to do that optimization?
>> In my opinion, It is better if do some change. Thanks again.
>
>I'm not quite following you. I don't believe there's any need to change
>anything nor any need to optimize anything.
>
>Can you elaborate on what issue you are facing?
>
>Best,
>-jay
>
>> At 2017-03-08 00:57:51, "Jay Pipes" <jaypi...@gmail.com> wrote:
>>>On 03/07/2017 01:34 AM, zengchen wrote:
>>>> Hi, guys:
>>>> I find a non-coincidence definition in Oslo,
>>>>
>>>> oslo_utils.timeutils.utcnow is defined like this:
>>>> def utcnow(with_timezone=False):
>>>>
>>>> oslo_versonedobjects.fields.DateTimeField is defined like this
>>>> classDateTimeField(AutoTypedField): def__init__(self, tzinfo_aware=True,
>>>> **kwargs):
>>>>
>>>> a = utcnow()
>>>> class ABC(VersionedObject):
>>>> fields = {
>>>> created_at = fields.DateTimeField()
>>>> }
>>>> b = ABC(), and fill it by db record.
>>>>
>>>> If I compare a and b.created_at, it will raise an exception like this:
>>>> 'TypeError: can't compare offset-naive and offset-aware datetimes'
>>>> because a's value is like this:
>>>> datetime.datetime(2017, 3, 7, 2, 34, 50, 859002)
>>>> b.created_at 's value is like this:
>>>> datetime.datetime(2017, 3, 7, 2, 35, 27,
>>>> 400786,*tzinfo=<iso8601.Utc>*)
>>>>
>>>> Can these two kinds of time's definition be coincident? For example:
>>>> def utcnow(with_timezone=*False*):
>>>>
>>>> class DateTimeField(AutoTypedField):
>>>> def __init__(self, tzinfo_aware=*False*, **kwargs):
>>>
>>>Hi Zeng,
>>>
>>>Yes, you will want to use utcnow(with_timezone=True) and the default
>>>ovo.fields.DateTimeField definition *or* use utcnow() and a
>>>ovo.fields.DateTimeField(tzinfo_aware=False) definition.
>>>
>>>Best,
>>>-jay
>>>
>>>__________________________________________________________________________
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
