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

[John Arbash Meinel]

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

James Henstridge wrote:
> On 03/01/07, John Arbash Meinel <john at arbash-meinel.com> wrote:
>> 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)
> 
> Yep, that's the reason for not ignoring the days portion of the interval.
> 
> 
>> 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)
> 
> Attached is a bundle that reduces the range of offsets that the test
> will accept to -18 hours to +18 hours.  The rest is the same.
> 
> James.

+1 from me. I'm not sure why BB hasn't picked it up. Possibly because it
is a follow up email?

John
=:->

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

iD8DBQFFnSLcJdeBCYSNAAMRAvK0AJ4nt6bOIYO/W6J33SVEQaR8OzfSQACfZ/gS
Z+37Z/LdLXNx+mdkSmUEpxU=
=F6DJ
-----END PGP SIGNATURE-----