[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
-----BEGIN PGP SIGNED MESSAGE-----
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.
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)
It is true that that equation can return all sorts of values, the trick
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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar