[spyne] primitive.DateTime: Attribute.validate_native problem

Burak Arslan burak.arslan at arskom.com.tr
Mon Sep 29 13:12:41 UTC 2014

On 09/29/14 15:50, Roberto Maurizzi wrote:
>     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 <http://cls.Attributes.gt>
>     is cls._min_dt or value > cls.Attributes.gt
>     <http://cls.Attributes.gt>)
>                     and value >= cls.Attributes.ge
>     <http://cls.Attributes.ge>
>                     and (cls.Attributes.lt <http://cls.Attributes.lt>
>     is cls._max_dt or value < cls.Attributes.lt
>     <http://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.

My code fragment above ended up like so:


> 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 ;-) )

Nope, in this case, your client is right. The value *is* valid and
should not have any issues with validation.

> 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.

dealing with timezones (not just in Python) are a huge pain and TBH,
explaining why Spyne works the way it does warrants a whole blog post of
its own.

But in short, spyne needs datetimes to always have a time zone. it
doesn't touch values with time zones but values without ones are treated
as spyne.LOCAL_TZ, which happens to be UTC. I can't think of a single
reason why someone would need some other value there.

> 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

You will find many inconsistencies like this. The controversy about the
time in indiana is a funny read:

if you can come up with test cases (preferably in pull requests!)
showing Spyne's soft validation doing the wrong thing on date range
constraints, I'd be happy to fix them for you.

best regards,

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

More information about the people mailing list