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

[James Henstridge]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: local-time-offset-fix.patch
Type: text/x-patch
Size: 6836 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070104/8dfbd875/attachment-0001.bin