Current: If I want to create a datetime object with a particular timezone offset, I have to do this:
    
    import datetime
    mytime = datetime.datetime(2015, 10, 16, 9, 13, 0, tzinfo=datetime.timezone(datetime.timedelta(hours=-7)))

Or with imports:

    from datetime import datetime, timezone, timedelta
    mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=timezone(timedelta(hours=-7)))

That's two extra imports and two extra objects created.


Requested way:
    mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=-7)
    # mytime.tzinfo == -7

Or if someone doesn't like the `tzinfo` keyword:
    mytime = datetime(2015, 10, 16, 9, 13, 0, tzhours=-7)
    # mytime.tzinfo == timezone(timedelta(-7))


For timezones, hours are the normal unit of time. At least, I think about time zones in hours, and I don't know who would think about them in minutes. There are half-hour offsets, so floats make sense to have.

Imagine you have about a year of experience dabbling in Python, and you're trying to do a relatively simple task, like reading PDT times and converting them to local time. You would go to the datetime docs, see that you need to pass in a tzinfo object. You look that up, and run into this:
"""tzinfo is an abstract base class, meaning that this class should not be instantiated directly. You need to derive a concrete subclass, and (at least) supply implementations of the standard tzinfo methods needed by the datetime methods you use."""

Well, great. If you want to convert times, you'll have to subclass an abstract base class, and implement five methods. You'd probably have to read the whole docs for this class, too. (The docs for tzinfo take nine Page Downs for me to scroll past.)

If you're not frightened off by the first two sentences, you'll see that there's the concrete subclass `datetime.timezone`. We're two levels down, now. Going there, you'll see that you need to pass in a timedelta object. Three levels. You need to learn about three classes just to specify an hour offset.

Timezones are something that many non-programmers understand, and the rules are pretty simple (barring DST, but the library doesn't really deal with it anyway). Ideally, it should be simple to do simple things.


PS: There seems to be unnecessary inconsistency with `.astimezone`, `fromtimestamp`, and `now` taking a `tz` kwarg rather than a `tzinfo` kwarg.

timezone is relatively new.  Work is in progress to add better timezone support to datetime, but it is a complicated subject and may or may not make it into 3.6.  In any case I think it is too soon to talk about this kind of API change, before the other work gets farther along.  That's probably also true for changes to the docs, although a concrete proposal there might have some chance.

There's a mailing list for talking specifically about datetime issues, you might want to post there (see mail.python.org, datetime-sig).

Thanks. Will visit them.