One of the issues in our issue tracker fails to display in the web interface because the exception in the summary.

The backtrace and issue history is listed in the appended text file.

This is using 1.4.6 with Python 2.4.

Maybe <Date 2008-09-11.14:02:59.998> was somehow rounded to :60?

I just got the same crash in roundup-admin and web interface.
In my case I got a journal entry with <Date 2010-10-28.14:34:60.000000>

My very ugly workaround was to change _utc_to_local() in roundup/date.py to:

    try:
        ...existing code...
    except ValueError:
        return (1970,1,1,12,0,0)

Same problem here with the current Ubuntu (maverick) version of roundup,
which they call 1.4.13-3.1 (so presumably based on 1.4.13) using Python
2.6.6.

I reported this as an issue with Ubuntu's roundup package here:
https://bugs.launchpad.net/ubuntu/+source/roundup/+bug/673677
I fixed the problem locally by capping the seconds field to the range
0..59 (see patch behind that link).

Meta-question: should I not bother submitting roundup bugs at Ubuntu's
launchpad site? The previous issue I reported there did not get any
reaction after more than a year:
https://bugs.launchpad.net/ubuntu/+source/roundup/+bug/469013

I have two test cases now in older tracker versions.
I'm planning to migrate them to roundup 1.5.x very soon, so I can see if
your patch is still needed (I assume that it is, the code is still
unchanged) and apply it to the Roundup repository (where I now have push
access).

Related or maybe the same problem:
issue2550802
roundup.date.Date()s formatted using serialise may get a seconds part of
60.000

It seems this tracker does not generate a link to issue 2550802 (now
trying with an additional space)
To be sure, here is the full URL:
http://issues.roundup-tracker.org/issue2550802

changeset:   4856:392a055fdc21
tag:         tip
user:        Thomas Arendsen Hein <thomas@intevation.de>
date:        Tue Feb 11 09:38:31 2014 +0100
files:       CHANGES.txt roundup/date.py
description:
issue2117897: Fixed two more rounding to 60.0 seconds in date.py

This caused exceptions in real-world data as reported in the issue by
Kenny Johansson, Malte Helmert and me. Change them to 59.999 as was done
in the fix for issue2550802.