[MERGE] make local_time_offset() more reliable (bug 77588)

John Arbash Meinel john at arbash-meinel.com
Tue Jan 2 18:32:03 GMT 2007

Hash: SHA1

Alexander Belchenko wrote:


>> Sure, I just didn't know why.
>> I'm not really concerned, because timezones should really only go +- 12
>> hours (with some small fudging because of Daylight savings time, etc).
>> If a timezone was actually configured to be +24 hours, I think we would
>> probably want it flagged.
>> I would actually like something more like +-15 hours, but I don't know
>> what a safe margin is for real-life.
>> But we can go either way. If you want, I can switch it, and then merge.
> I really don't know. When I look at this:
> return offset.days * 86400 + offset.seconds
> I see that it possible to have more than +- 24 hours offset. I just
> don't understand how bzr should handle this.
> -- 
> Alexander

I'm pretty sure this is just because offset.days may be a negative
number. Just because of how datetime handles negative dates.
Specifically, I believe it requires seconds and microseconds to always
be positive numbers. For example:

>>> datetime.timedelta(0, -100, 0)
datetime.timedelta(-1, 86300)

It is true that that equation can return all sorts of values, the trick
is that:

offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t)

If the local date from timestamp differs from the utc date from
timestamp by more than 24 hours, we have a real problem.

It might be more obvious to write these as:

return offset.days * (24*60*60) + offset.seconds

and then do:

# It is possible for timezones to be +-12, and even +-13 because of
# daylight savings time, so we add a little fudge to avoid spurious
# errors, but if we are >+-18 hours, we probably have a problem.
eighteen_hours = 18*60*60
self.assertTrue(-eighteen_hours < offset < eighteen_hours)

Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list