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

[James Henstridge]

Same patch, but with a different email subject line so that bundle
buggy picks it up.

On 02/01/07, James Henstridge <james at jamesh.id.au> wrote:
> Western Australia recently adopted a three year daylight savings
> trial.  This meant that December of 2006 was in +0900 while the rest
> of the year had been +0800.
>
> Even though I'd applied a time zone data update to my computer, I
> noticed that Bazaar was still recording the time zone offset for
> commits in December as +0800.
>
> I did a bit of investigation, and it turns out that the way the
> time.timezone and time.altzone constants were being calculated meant
> that they both got set to 8 hours if Python was run in 2006 (it checks
> the offsets at the beginning of the year and middle of the year --
> both of which were at +0800).  There is a bit more info on the problem
> in the description of bug 77588.
>
> Attached is a bundle that changes local_time_offset() to a more
> reliable version that creates two datetime objects for the timestamp
> (one local and one UTC) and uses the difference between the two to
> calculate the offset.  This doesn't suffer from the timezone/altzone
> calculation bugs, and should give correct results for past or future
> times that use different rules to the present.
>
> There weren't any tests for the local_time_offset() function before,
> but my modified version returns the same results (except where the old
> version gave incorrect results).  I am not sure exactly how you'd test
> it in a platform neutral way though.  It is a very short function, so
> perhaps it doesn't need a direct test.
>
> James.
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: local-time-offset-fix.patch
Type: text/x-patch
Size: 1795 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070102/d36cfed5/attachment.bin