[Python-ideas] Date/time literals

[Marcos Bonci]

>From Masklinn's post in his blog:


> Sadly it seems that Java got it right: having one class (Date<http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html>)
> that stores times in UTC seconds relative to Unix Epoch, and subclasses of
> abstract Calendar<http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html> class
> that deal with getting and setting individual components and date arithmetic
> in a localized way would indeed be the best long-term solution.


That's exactly what I was talking about. Date/time is something
apparently near-trivial (it's something everyone deals with every
day), but awfully complicated when looked at in detail. This can
be very deceiving for the inexperienced/inattentive programmer,
and very inconvenient/time-wasting for the attentive one.

I like Python because I can usually rely on its "magic" and just
care about what's elegant and readable (or else I would be using C).
Judging from your personal experience, the magic looks more like
illusionism when it comes to dates. Maybe this matter deserves
closer attention in the context of the language/stdlibs than it has
received so far? After all it's time we're talking about, it's not like
it's something unimportant or rarely used (and it's something I
would definitely expect to be able to rely on Python for, since
pretty much everything else Python is just awesome).

There's just too many ways to do it, and none of them seem to
be good enough.

-- Marcos --


On 30 May 2010 05:28, Masklinn <masklinn at masklinn.net> wrote:

> On 2010-05-30, at 03:49 , Chris Rebert wrote:
> > On Sat, May 29, 2010 at 6:05 PM, Marcos Bonci <marcos.bonci at gmail.com>
> wrote:
> >> Hi!
> >> I've been working a lot with date/time variables lately, and maybe it's
> just
> >> me, and
> >> maybe I just don't get it yet, but it sure doesn't feel like there's
> >> one-and-only-one
> >> elegant, obvious way to work with them. Feels like working with strings
> in
> >> C.
> >
> > Reading the rest of your post, it sounds like you're unaware of the
> > fairly nice API of the `datetime` std lib module:
> > http://docs.python.org/library/datetime.html
> >
> > IMO, it's pretty nice to work with; although it is annoying that some
> > operations can only be done using the more primitive `time` or
> > `calendar` modules. Patches are probably welcome; perhaps I should
> > consider trying to write one.
>
> datetime does have a bunch of issues and limitations which I believe soon
> become harmful when doing serious date/calendaring works (which I don't
> claim to do, but I've seen colleagues in serious trouble due to both
> personal lack of knowledge in the field and issues with datetime itself):
> it only supports a gregoriany calendar for instance, it's horrendous
> in dealing with timezones, some methods are pretty much broken,
> constructor refuses "24" as an hour value, blows up on positive leap
> seconds)…
>
> See the following resources for issues with datetime:
>
> http://blog.mfabrik.com/2008/06/30/relativity-of-time-shortcomings-in-python-datetime-and-workaround/
> http://www.enricozini.org/2009/debian/using-python-datetime/
>
> Libraries built over datetime:
> http://labix.org/python-dateutil
> http://pytz.sourceforge.net/ [1]
>
>
> [1] note that as mentioned in the first blog post, datetime apparently
> has issues re querrying tz objects, so it's generally suggested to work
> with utc-only datetime objects and let the timezone stuff to direct
> pytz calls.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100530/3fcd5e10/attachment.html>