[jessedhillon]

IMO dateutil provides this in a more transparent way by providing tzinfo subclasses:

    py> from dateutil.tz import gettz
    py> from datetime import datetime

    py> new_york = gettz('America/New York')
    py> los_angeles = gettz('America/Los Angeles')
    py> minsk = gettz('Europe/Minsk')

    py> fmt = "%Y-%m-%d %H:%M%z"
    py> datetime.now(new_york).strftime(fmt)
      '2012-02-03 01:51-0500'
    py> datetime.now(los_angeles).strftime(fmt)
      '2012-02-02 22:51-0800'
    py> datetime.now(los_angeles).astimezone(minsk).strftime(fmt)
      '2012-02-03 09:51+0300'

For me, the most annoying thing about Python is that out of the box, AFAICT, you cannot get a TZ-aware datetime. In fact, while tzinfo is part of the standard library, I don't know of any included solution for making TZ-aware datetime, short of writing your own subclasses for each timezone.

EDIT: datetime.utcnow() is TZ-aware, I meant any other timezone.

[j2labs]

I agree that dateutil is excellent. I think it's also worth mentioning how powerful dateutil's `parse()` is. You can pass virtually any string representation of a date to it and it will return a Python datetime.

[masklinn]

> For me, the most annoying thing about Python is that out of the box, AFAICT, you cannot get a TZ-aware datetime.

That's because the stdlib would have to get updated every 3-6 months, which it is not. Hence delegating to e.g. pytz for timezones provision.

> I don't know of any included solution for making TZ-aware datetime, short of writing your own subclasses for each timezone.

There isn't indeed, because there can't be an stdlib-provided way to do this which is actually correct.

[thristian]

dateutil includes tzinfo implementations 'tzutc' (whose offset is always zero), 'tzoffset' (whose offset is passed as a parameter) and 'tzlocal' (whose offset is the value of time.timezone). All these could easily and safely be implemented in the stdlib without having to push out updates every time the Olson timezone database has a new release.

It also contains tzinfo implementations that read timezone definitions from a system-wide copy of the Olson database (for most POSIX OSs) or the registry (for Windows-based OSs). These could also be added to the standard library without requiring regular Python updates, because the OS's usual timezone update system will take care of things.

Perhaps the stdlib can't possibly solve timezone issues in all possible cases, but it could be a lot more useful than it currently is.

[mvanveen]

dateutil is really great; j2labs is quick to point out `parse()` which I also think is worth mentioning on its own.

I think this project still fills a nice niche. datetime.now(los_angeles).astimezone(minsk).strftime(fmt) is long enough that you're going to have to find the StackOverflow thread in question to implement this, and maybe go to the stdlib. This library makes that a lot less painful.

If you go to the source, you'll see how tiny it is! It's nowhere near the complexity of dateutil. I'd love to see some of dateutil's darker corners wrapped into this library.