PATCH: make local_time_offset() more reliable (bug 77588)

[James Henstridge]

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/ecb12903/attachment.bin