On Fri, Dec 11, 2015 at 11:46 AM, Chris Barker chris.barker@noaa.gov wrote:

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!

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

Is that because information about political timezone has been lost, or because there is a real need for arithmetic on a fixed-offset non-zero timezone? If the former, any sort of arithmetic is meaningless, so all that can really be done is convert it to UTC. (Which can be done pretty easily with a timedelta.)

...

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.

You mean PEP 431, withdrawn by its author? I think that post-PEP-495, this could be revived (or an equivalent put together).

What I'd like to see is a simple recipe for an aware datetime, nice and high in the docs. The best I've found is this:

https://docs.python.org/3.5/library/datetime.html#datetime.datetime.utcnow

which suggests that datetime.datetime.now(datetime.timezone.utc) is the way to do this. If that is indeed the correct solution, it'd be good to push that higher in the docs. If it isn't, there definitely needs to be something else. I'm also more than a little confused about the right way to construct non-now() aware datetimes, as this appears to work:

datetime.datetime(2015,12,11,1,34,49,tzinfo=datetime.timezone.utc)

but people recommend pytz.localize instead.

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 can't think of any real-world use-cases for an actual fixed-offset timezone. Usually these are either fake (like when you parse an RFC822 time), or incorrect (when you're trying to represent "local time" in any way - although it might happen to mostly work in places without DST). OP, can you explain more of what you're needing?

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?

With the understanding that UTC offsets can be fractional hours, yes, this might be a useful short-hand. Most places in the world have offsets that are a multiple of 0.25 hours, so float hours would cover that easily. Working with historical times usually will need the proper tzinfo database anyway.

ChrisA