Hi jay: Understand you. It is a good method! I will try to update my codes.
Really appreciate your reply. Thanks! Best Wishes! zeng chen At 2017-03-10 02:52:55, "Jay Pipes" <jaypi...@gmail.com> wrote: >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" <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 >> > >__________________________________________________________________________ >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