"Franklin? Lee" <[email protected]> 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 > [email protected] > https://mail.python.org/mailman/listinfo/datetime-sig > The PSF Code of Conduct applies to this mailing list: > https://www.python.org/psf/codeofconduct/ _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
