[spyne] primitive.DateTime: Attribute.validate_native problem

Roberto Maurizzi roberto.maurizzi at gmail.com
Mon Sep 29 12:50:39 UTC 2014

> Hello Roberto, Welcome!

> Hmmm. That's python's fault for making boundary values valid ones.
> Maybe we can skip gt (and lt) test when it's equal to smallest (and
> largest) datetime?
>         return SimpleModel.validate_native(cls, value) and (
>             value is None or (
>                     (cls.Attributes.gt is cls._min_dt or value >
> cls.Attributes.gt)
>                 and value >= cls.Attributes.ge
>                 and (cls.Attributes.lt is cls._max_dt or value <
> cls.Attributes.lt)
>                 and value <= cls.Attributes.le
>             ))
> Do you think that'd be enough?

I did try to simply comment out the value > cls.Attributes.gt
<http://cls.attributes.gt/> case and it works, however:
1) testing your code I don't have any DateTime._min_dt (from cls._min_dt)
[spyne 2.11]
2) I'm not so sure a boundary value should be rejected "hard", as a
concept... if we had positive nonzero integers would you reject 1? A
Boundary has a special meaning and it's often used just because of that.

Granted, my case is a very ugly one and the proper fix would be to change
the WinMobile client to return a less 'strange' value (or even
better,  rewrite it for Android and run it on rugged phones/tablets ;-) )

Related to this, while I was experimenting with pytz.timezone, I discovered
the "wonderful world" of LMT... and I totally fail to understand why it
works like it does.

If I create a tz-aware datetime using datetime.datetime(y,m,d,h,m,s, m, tz)
(as in Spyne's DateTime) it can either work OR NOT depending on what is tz.
UTC works, some other timezone works, but many others will give you things
like this:

In [4]: tz_dubai = pytz.timezone("Asia/Dubai")

In [5]: tz_london = pytz.timezone("Europe/London")

In [6]: dubai_time = datetime.datetime(2014, 9, 29, 12, 0, 0, 0, tz_dubai)

In [7]: print dubai_time
2014-09-29 12:00:00+03:41

In [8]: print dubai_time.astimezone(tz_london)
2014-09-29 09:19:00+01:00

In [9]: print dubai_time.astimezone(tz_london).astimezone(tz_dubai)
2014-09-29 12:19:00+04:00

According to some sources the right way to create/convert a tz-aware
timestamp is to use something like:

In [12]: tz_dubai.localize(datetime.datetime.now())
Out[12]: datetime.datetime(2014, 9, 29, 16, 32, 38, 141302,
tzinfo=<DstTzInfo 'Asia/Dubai' GST+4:00:00 STD>)

instead of:

In [13]: datetime.datetime(2014, 9, 29, 16, 32, 38, 141302, tzinfo=tz_dubai)
Out[13]: datetime.datetime(2014, 9, 29, 16, 32, 38, 141302,
tzinfo=<DstTzInfo 'Asia/Dubai' LMT+3:41:00 STD>)

Now I really wonder what the Attributes limits should use for cases when
spyne.LOCAL_TZ is changed from UTC and set to some 'wrong' timezone (btw,
Python's docs say the 'strange behaviour' comes from timezones that can
have DST... but the UAE don't use DST...  @___@; )

And here  I though SOAP was overly complex...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spyne.io/archives/people/attachments/20140929/8dc1a89e/attachment.html>

More information about the people mailing list