Hi Jeff,<div><br></div><div>Thanks for your answer. I think you followed perfectly by reading your answer. I talk only about received objects. So far I didn&#39;t send any.</div><div><br></div><div>The issue (as I see it) is that the returned datetime is a &quot;naive&quot; object, and we live in a world with timezones, daylight saving schemes. And Python does not mix naive and timezone-aware objects.</div>
<div><br></div><div>The options you suggest:</div><div><br></div><div>a) Returning UTC objects. If there were a generic tz object describing this timezone this would be the best approach. Since coordination of time has to be referenced to UTC and the object could later be used with &quot;astimezone(xxx)&quot; to return objects adapted to the timezone to be displayed to users</div>
<div><br></div><div>b) Option in suds to apply a tz object for returned objects. This can be possibly seen as an extension of a), since a general UTC tz object would be replaced by the tz object supplied by the user. But thinking of applications where the user can change the timezone, applying &quot;astimezone(xxx)&quot; would be required again.</div>
<div><br></div><div>In my opinion &quot;a&quot; (given the existence of a generic tz object) is the optimal.</div><div><br></div><div>And talking about a generic UTC tz object, this should be at least definable, since UTC does not have DST settings (UTC is fixed, it is only the countries moving away from it or getting closer to it with DST)</div>
<div><br></div><div>Best regards</div><div><br></div><div>Daniel</div><div><br></div><div><div class="gmail_quote">On Tue, Mar 30, 2010 at 15:00, Jeff Ortel <span dir="ltr">&lt;<a href="mailto:jortel@redhat.com">jortel@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey Daniel,<br>
<br>
Not sure I follow.  Suds converts received xs:datetime to a python datetime object that has been adjusted to the local timezone.  When sending a datetime, it is sent with TZ offset.  Are you suggesting a suds /option/ that would return the xs:datetime in UTC instead of the local TZ?  Or, an options for suds to return a datetime object with tz_info set?<br>

<br>
Thanks,<br>
<br>
Jeff<div><div></div><div class="h5"><br>
<br>
On 03/29/2010 02:52 AM, Daniel Rodriguez wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
Hi Jeff et al,<br>
<br>
I was wondering what you and others think about always returning<br>
timezone-aware datetime objects. The default timezone would be UTC (GMT).<br>
<br>
If the user of the library knows that the default timezone for an object<br>
is not UTC he can then use &quot;replace&quot; to change the timezone without<br>
changing the fields.<br>
<br>
I personally would see it as positive, since I find terrible to rebuild<br>
a datetime object just to make the conversion from naive to timezone-aware.<br>
<br>
Best regards<br>
<br>
Daniel<br>
<br>
<br>
<br>
<br></div></div>
_______________________________________________<br>
suds mailing list<br>
<a href="mailto:suds@lists.fedoraproject.org" target="_blank">suds@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/suds" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/suds</a><br>
</blockquote>
<br>
<br>_______________________________________________<br>
suds mailing list<br>
<a href="mailto:suds@lists.fedoraproject.org">suds@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/suds" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/suds</a><br></blockquote></div><br></div>