[MERGE] make local_time_offset() more reliable (bug 77588)
John Arbash Meinel
john at arbash-meinel.com
Thu Jan 4 15:53:00 GMT 2007
-----BEGIN PGP SIGNED MESSAGE-----
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.
+1 from me. I'm not sure why BB hasn't picked it up. Possibly because it
is a follow up email?
-----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