[Datetime-SIG] Allow numerical arguments for timezones

[Akira Li]

"Franklin? Lee" <leewangzhong+python at gmail.com> 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 at 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/