"Franklin? Lee" writes:

(Originally posted at http://bugs.python.org/issue25428)

Proposal: Functions in `datetime` which take a `tzinfo` object should allow, as an alternative, a numerical argument, which would be interpreted as the number of hours. There are time zones with half-hour offsets, so floats should be allowed.

Current: To create a `datetime` object with a particular time zone offset,

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.

Suggested way: mytime = datetime(2015, 10, 16, 9, 13, 0, tzinfo=-7) # mytime.tzinfo == -7 # or: mytime.tzinfo == timezone(timedelta(-7))

Alternatively, introduce a new keyword parameter to explictily indicate hours: mytime = datetime(2015, 10, 16, 9, 13, 0, tzhours=-7) # mytime.tzinfo == timezone(timedelta(-7))

timedelta(-7) is 7 *days* Such simple errors are an argument against using unlabeled integers instead of objects that know that they represent days, hours, etc.

Rationale:

For time zones, 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.

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, and see that you need to pass in a tzinfo object. You look up `tzinfo`:

"""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 (if you know what that means), and implement five methods. You'd probably have to read the whole docs for this ABC, too. (The docs for `tzinfo` are nine pages long on my screen.)

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 `datetime.timedelta` object. Three levels. You need to learn three classes to specify an hour offset: `tzinfo`, `timezone`, and `timedelta`.

Time zones are something that many non-programmers understand, and the rules are pretty simple (except for DST). Ideally, it should be simple to do simple things.

Using integers would encourage a wrong model. It is incorrect to equate a utc offset and a time zone. Many time zones have different utc offsets at different dates. Most areas in North America and Europe observe DST https://en.wikipedia.org/wiki/Daylight_saving_time_by_country I would understand if you were to suggest to use the timezone names, to simplify usage: dt = datetime(2015, 10, 16, 9, 13, 0, tzinfo='America/Los_Angeles') The only way to get a reasonable (on the scale of correctness vs. complexity tradeoffs) answer is to use libraries built on top of *pytz* package at the moment: tz = pytz.timezone('America/Los_Angeles') dt = tz.localize(datetime(2015, 10, 16, 9, 13), is_dst=None)

PS: There seems to be an unnecessary naming inconsistency with `.astimezone`, `fromtimestamp`, and `now` taking a `tz` kwarg rather than a `tzinfo` kwarg. _______________________________________________ Datetime-SIG mailing list Datetime-SIG@python.org https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/