Wrong timezone in list archive index pages

[Schoinobates]

This is Debian bug #352876 (see
http://bugs.debian.org/352876)

The timezone used on the list archive index pages for
the starting, ending, last message and archived on
dates is wrong. All these times are given in GMT (the
standard timezone for the UK) but are claimed to be BST
(British Summer Time, the daylight saving time used
between March and October, equivalent to GMT+1).

For example, the last message to one of my lists was
sent at Fri, 10 Feb 2006 10:07:40 +0000, but according
to the archives by thread page, the ending and last
message dates are "Fri Feb 10 10:07:40 BST 2006". The
timezone is correct in the archive page for the message
though, where it is given as "Fri Feb 10 10:07:40 GMT 2006"

The times given during the summer are correct, where
everything is in BST.

Original submitter claims timezone data and clock is
correct on the machine.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1433673&group_id=103&atid=100103]

[Mark Sapiro (msapiro)]

The underlying problem is a bug in i18n.ctime().

When i18n.ctime is passed a time string, it uses
time.strptime() to convert the string into a struct_time. If
the string doesn't contain a time zone, strptime() returns
tm_isdst = -1 which the following code treats as 1 rather
than unknown.

The attached patch (2.1.7 base) will use the phrase "Server
Local Time" translated into the list language instead of BST
or whatever.

[Mark Sapiro (msapiro)]

Patch has been committed to CVS.

[Rogerlynn (rogerlynn)]

Isn't the real problem that the time zone has been stripped
from the string in the first place?

[Mark Sapiro (msapiro)]

>Isn't the real problem that the time zone has been
>stripped from the string in the first place?

Sort of. The problem here is that the string is produced by
time.asctime() which doesn't put a timezone in the string.
Changing this would be a significant change to the archiver
which might well break something else - at least if I did it :-)

[Mark Sapiro (msapiro)]

I've thought about this some more and I've come up with a
different fix which will use tm_isdst from time.localtime()
in those cases where time.strptime() returns tm_isdst = -1.
Thanks to Roger Lynn for the motivation.