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

[Alexander Belchenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel пишет:
> 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.

Does the bzr core library check this limits?

> 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)

You convince me.
+1.

- --
Alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFmwukzYr338mxwCURAiGCAKCSlvlkklIDg2eEHQmmGdnFG8MLfwCfRvFx
2ZIz975sbt6m5eCXpVQG+Xc=
=A2Ua
-----END PGP SIGNATURE-----