[Datetime-SIG] Allow numerical arguments for timezones

[Chris Barker]

yeah, now that datetime has the fixed offset timezone object out of the
box, this may well make sense.

On Wed, Dec 9, 2015 at 3:38 AM, Akira Li <4kir4.1i at gmail.com> wrote:

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

Except he made this error creating the timedelta object anyway -- so no
help there. But a new keyword would make this pretty clear:

mytime = datetime(2015, 10, 16, 9, 13, 0, tzhours=-7)

if you can't figure out that tzhours is expected to be units of hours, we
can forget the whole thing!

I have to agree:

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

is pretty wordy, and requires a fair bit of digging into the docs to
understand. though an example of this in the docs would be a good start.

And yes, in the general case, "timezones" are NOT fixed-offset -- but
working with fixed-offset data is pretty common.

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')
>

well, that's a whole other ball of wax, requiring a database that's
maintained. There was a PEP For that, but I don't think it's going forward.

but anyway, the OP WANTS a fixed-offset -- NOT a region, politically driven
timezone -- there should be a way to get that easily -- the only issue is
whether explicitly creating a timezone object with a timedelta object s
easy enough.

I'm actually surprised that the built- in timezone class takes a timedelta
-- this seems to be a heavyweight object-oriented, statically types style
approach :-) -- I've never seen a timezone offset described anyting other
than hours -- why not use that?

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20151210/826a3e08/attachment.html>