<div>From Masklinn's post in his blog:</div><div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

Sadly it seems that Java got it right: having one class (<a onclick="javascript:urchinTracker ('/outgoing/java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html');" title="java.util.Date documentation" href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html" style="background-color: transparent; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; "><font class="Apple-style-span" color="#000000"><span class="Apple-style-span" style="text-decoration: none;">Date</span></font></a>) that stores times in UTC seconds relative to Unix Epoch, and subclasses of abstract <a onclick="javascript:urchinTracker ('/outgoing/java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html');" title="java.util.Calendar documentation" href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html" style="background-color: transparent; border-top-width: 0px; border-right-width: 0px; border-bottom-width: 0px; border-left-width: 0px; border-style: initial; border-color: initial; "><font class="Apple-style-span" color="#000000"><span class="Apple-style-span" style="text-decoration: none;">Calendar</span></font></a> class that deal with getting and setting individual components and date arithmetic in a localized way would indeed be the best long-term solution.</blockquote>

<meta charset="utf-8"><div><br></div><div>That's exactly what I was talking about. Date/time is something</div><div>apparently near-trivial (it's something everyone deals with every</div><div>day), but awfully complicated when looked at in detail. This can</div>

<div>be very deceiving for the inexperienced/inattentive programmer,</div><div>and very inconvenient/time-wasting for the attentive one.</div><div><br></div><div>I like Python because I can usually rely on its "magic" and just</div>

<div>care about what's elegant and readable (or else I would be using C).</div><div>Judging from your personal experience, the magic looks more like</div><div>illusionism when it comes to dates. Maybe this matter deserves</div>

<div>closer attention in the context of the language/stdlibs than it has</div><div>received so far? After all it's time we're talking about, it's not like</div><div>it's something unimportant or rarely used (and it's something I</div>

<div>would definitely expect to be able to rely on Python for, since</div><div>pretty much everything else Python is just awesome).</div><div><br></div><div>There's just too many ways to do it, and none of them seem to</div>

<div>be good enough.</div><br>-- Marcos --<br>
<br><br><div class="gmail_quote">On 30 May 2010 05:28, Masklinn <span dir="ltr"><<a href="mailto:masklinn@masklinn.net">masklinn@masklinn.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On 2010-05-30, at 03:49 , Chris Rebert wrote:<br>
> On Sat, May 29, 2010 at 6:05 PM, Marcos Bonci <<a href="mailto:marcos.bonci@gmail.com">marcos.bonci@gmail.com</a>> wrote:<br>
>> Hi!<br>
>> I've been working a lot with date/time variables lately, and maybe it's just<br>
>> me, and<br>
>> maybe I just don't get it yet, but it sure doesn't feel like there's<br>
>> one-and-only-one<br>
>> elegant, obvious way to work with them. Feels like working with strings in<br>
>> C.<br>
><br>
> Reading the rest of your post, it sounds like you're unaware of the<br>
> fairly nice API of the `datetime` std lib module:<br>
> <a href="http://docs.python.org/library/datetime.html" target="_blank">http://docs.python.org/library/datetime.html</a><br>
><br>
> IMO, it's pretty nice to work with; although it is annoying that some<br>
> operations can only be done using the more primitive `time` or<br>
> `calendar` modules. Patches are probably welcome; perhaps I should<br>
> consider trying to write one.<br>
<br>
</div>datetime does have a bunch of issues and limitations which I believe soon<br>
become harmful when doing serious date/calendaring works (which I don't<br>
claim to do, but I've seen colleagues in serious trouble due to both<br>
personal lack of knowledge in the field and issues with datetime itself):<br>
it only supports a gregoriany calendar for instance, it's horrendous<br>
in dealing with timezones, some methods are pretty much broken,<br>
constructor refuses "24" as an hour value, blows up on positive leap<br>
seconds)…<br>
<br>
See the following resources for issues with datetime:<br>
<a href="http://blog.mfabrik.com/2008/06/30/relativity-of-time-shortcomings-in-python-datetime-and-workaround/" target="_blank">http://blog.mfabrik.com/2008/06/30/relativity-of-time-shortcomings-in-python-datetime-and-workaround/</a><br>


<a href="http://www.enricozini.org/2009/debian/using-python-datetime/" target="_blank">http://www.enricozini.org/2009/debian/using-python-datetime/</a><br>
<br>
Libraries built over datetime:<br>
<a href="http://labix.org/python-dateutil" target="_blank">http://labix.org/python-dateutil</a><br>
<a href="http://pytz.sourceforge.net/" target="_blank">http://pytz.sourceforge.net/</a> [1]<br>
<br>
<br>
[1] note that as mentioned in the first blog post, datetime apparently<br>
has issues re querrying tz objects, so it's generally suggested to work<br>
with utc-only datetime objects and let the timezone stuff to direct<br>
pytz calls.</blockquote></div><br>