<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 09/29/14 15:50, Roberto Maurizzi wrote:<br>
    <blockquote
cite="mid:CAM4NGPb4e3fwbPr5Dt0AeEWp6KAgVJH42aazKsM9z7V-5jsi9Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">Hello Roberto,
                Welcome!<span class=""><br>
                  <br>
                </span></div>
            </blockquote>
            <div><br>
            </div>
            <div>:-)</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><span class=""> </span>Hmmm.
                That's python's fault for making boundary values valid
                ones.<br>
                <br>
                Maybe we can skip gt (and lt) test when it's equal to
                smallest (and largest) datetime?<br>
                <br>
                        return SimpleModel.validate_native(cls, value)
                and (<br>
                            value is None or (<br>
                                    (<a moz-do-not-send="true"
                  href="http://cls.Attributes.gt" target="_blank">cls.Attributes.gt</a>
                is cls._min_dt or value > <a moz-do-not-send="true"
                  href="http://cls.Attributes.gt" target="_blank">cls.Attributes.gt</a>)<br>
                                and value >= <a
                  moz-do-not-send="true" href="http://cls.Attributes.ge"
                  target="_blank">cls.Attributes.ge</a><br>
                                and (<a moz-do-not-send="true"
                  href="http://cls.Attributes.lt" target="_blank">cls.Attributes.lt</a>
                is cls._max_dt or value < <a moz-do-not-send="true"
                  href="http://cls.Attributes.lt" target="_blank">cls.Attributes.lt</a>)<br>
                                and value <= cls.Attributes.le<br>
                            ))<br>
                <br>
                Do you think that'd be enough?<span class=""><br>
                </span></div>
            </blockquote>
          </div>
          <br>
        </div>
        <div class="gmail_extra">I did try to simply comment out the
          value > <a moz-do-not-send="true"
            href="http://cls.attributes.gt/" target="_blank">cls.Attributes.gt</a> case
          and it works, however:</div>
        <div class="gmail_extra">1) testing your code I don't have any
          DateTime._min_dt (from cls._min_dt) [spyne 2.11]<br>
          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.</div>
      </div>
    </blockquote>
    <br>
    My code fragment above ended up like so:
<a class="moz-txt-link-freetext" href="https://github.com/plq/spyne/commit/f00cb1aea66d72354330677fd64bd527b369bc4b">https://github.com/plq/spyne/commit/f00cb1aea66d72354330677fd64bd527b369bc4b</a><br>
    <br>
     <br>
    <br>
    <blockquote
cite="mid:CAM4NGPb4e3fwbPr5Dt0AeEWp6KAgVJH42aazKsM9z7V-5jsi9Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">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 ;-) )<br>
        </div>
      </div>
    </blockquote>
    <br>
    Nope, in this case, your client is right. The value *is* valid and
    should not have any issues with validation.<br>
    <br>
    <blockquote
cite="mid:CAM4NGPb4e3fwbPr5Dt0AeEWp6KAgVJH42aazKsM9z7V-5jsi9Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <br>
          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.<br>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    <br>
    <br>
    <blockquote
cite="mid:CAM4NGPb4e3fwbPr5Dt0AeEWp6KAgVJH42aazKsM9z7V-5jsi9Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">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:<br>
          <br>
          <div class="gmail_extra">In [4]: tz_dubai =
            pytz.timezone("Asia/Dubai")</div>
          <div class="gmail_extra"><br>
          </div>
          <div class="gmail_extra">In [5]: tz_london =
            pytz.timezone("Europe/London")<br>
          </div>
          <div class="gmail_extra"><br>
          </div>
          <div class="gmail_extra">In [6]: dubai_time =
            datetime.datetime(2014, 9, 29, 12, 0, 0, 0, tz_dubai)</div>
          <div class="gmail_extra"><br>
          </div>
          <div class="gmail_extra">In [7]: print dubai_time</div>
          <div class="gmail_extra">2014-09-29 12:00:00+03:41</div>
          <div class="gmail_extra"><br>
          </div>
          <div class="gmail_extra">In [8]: print
            dubai_time.astimezone(tz_london)</div>
          <div class="gmail_extra">2014-09-29 09:19:00+01:00</div>
          <div class="gmail_extra"><br>
          </div>
          <div class="gmail_extra">In [9]: print
            dubai_time.astimezone(tz_london).astimezone(tz_dubai)</div>
          <div class="gmail_extra">2014-09-29 12:19:00+04:00</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    You will find many inconsistencies like this. The controversy about
    the time in indiana is a funny read:
    <a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Time_in_Indiana">http://en.wikipedia.org/wiki/Time_in_Indiana</a><br>
    <br>
    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.<br>
    <br>
    best regards,<br>
    burak<br>
    <br>
  </body>
</html>