Open Stack

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
>