Comparing offset-aware and offset-naive datetimes?

[Roy Smith]

I have two datetimes. One is offset-naive. The other is offset-aware,
but I happen to know its offset is 0 (i.e. GMT). How can I compare
these?

May the flies of a thousand Norwegian Blue parrots infest the armpits of
whoever invented timezones.

 

[Vito De Tullio]

I have two datetimes. One is offset-naive. The other is offset-aware,
but I happen to know its offset is 0 (i.e. GMT). How can I compare
these?

http://pytz.sourceforge.net/#localized-times-and-date-arithmetic

 

[Chris Angelico]

As further fuel for your hatred: GMT is not the same thing as UTC+0, and
never has been. (See the definitions of those two separate timezones for
more; Wikipedia's articles are probably a good start.)

For most people's purposes, GMT and UTC are equivalent. I tell people
that my D&D sessions are Sundays from 2:00 UTC to roughly 6:00-7:00
UTC, and if they treat that as GMT, they're not going to miss the
session. It's a lot better than a mess of "local time" with DST.

Timezones aren't a problem. Daylight/Summer time (or Ireland's
alternative, Winter time) is.

ChrisA

 

[Roy Smith]

As further fuel for your hatred: GMT is not the same thing as UTC+0, and
never has been. (See the definitions of those two separate timezones for
more; Wikipedia's articles are probably a good start.)

Yes, I am aware of the difference between GMT and UTC (and UT0, UT1,
etc). None of which really matters for my purpose. In this case, it
just so happens that the original string is:

Sat, 26 Jan 2013 20:10:34 GMT

so if anybody is conflating GMT and UTC, it's the dateutil parser

 

[Roy Smith]

Do you know the timezone of the offset-naive value?

Or is the above mixed up, and you mean “one is offset-aware; the other
is offset-naive, but I happen to know its offset is UTC+0�

Well, actually, what I wrote was correct, but incomplete.

The naive value came from a unix timestamp, so I know it is UTC. The
aware value came from dateutil's parsing of a string that looks like:

Sat, 26 Jan 2013 20:10:34 GMT

so I know that one's UTC too Unfortunately, the boto documentation
describes it only as "The string timestamp representing the last time
this object was modified in S3" without specifying the exact format.
I'm not sure if it's showing up in GMT because my server happens to be
running on GMT, or if it always does, so I'd rather let dateutil figure
it out for me.

In which case, you can create a new timezone-aware value using the
timezone-naive value and the timezone you've decided to apply::

That's what I ended up with, thanks:

s3_time = dateutil.parser.parse(s3_key.last_modified)
info = os.stat(file)
file_time = datetime.utcfromtimestamp(info.st_mtime)
utc = dateutil.tz.tzutc()
file_time = file_time.replace(tzinfo=utc)
if s3_time < file_time:

What I'm not fine with is politicians who think it's a fun game to
fiddle with the specific timezone definitions with little advance notice
and leave we programmers to clean up the mess they keep making. Those
people are sorely in need of a nasal infestation of parrot fleas.

Yes, indeed. I've been around long enough to remember when calendar
code had the "Nixon flag" and the "Ford flag", named for the first two
yahoos who started playing timekeeper for a day. That was before the
Olson database existed.