Open Stack

On 03/09/2017 01:37 AM, zengchen wrote:
> 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()

Instead of datetime.utcnow(), do:

  from oslo_utils import timeutils
  ...

  now = timeutils.utcnow(with_timezone=True)

Alternately, you might consider creating a closure that masks the 
with_timezone=True parameter. For instance, you could have a 
karbor.utils file that contains something like this:

  import functools

  from oslo_utils import timeutils


  utcnow = functools.partial(timeutils.utcnow, with_timezone=True)

and then in the file that has your resume_operation() method, you would 
instead:

  from karbor import utils
  ...

  now = utils.utcnow()

Best,
-jay

>     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" <jaypipes at 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" <jaypipes at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>