When the time zone is set to a "right" zone, the
conflict detection logic fails, preventing any issue
from being edited.  The "right" time zones (such as
"right/EST5EDT") are leap-second corrected, and
currently have a 22-second offset from uncorrected time.

When this offset is in place, parts of Roundup use the
time with the correction, and parts use without.  For
example, the specific issue we were working with had a
last activity time of "2004-11-26.23:10:02" according
to the web interface, but the database internally
listed "20041126231024.912868".

We are using Roundup version 0.7.9 with the SQLite
backend.  This may not apply to other back-ends.  We
were able to restore functionality by setting
TZ=EST5EDT when running Roundup.

Logged In: YES 
user_id=6405

ugh :) 

Looks like this was patched:

diff -r 8d5c95c33447 -r 7c8d2e9a0566 roundup/cgi/templating.py
--- a/roundup/cgi/templating.py Fri May 14 22:43:33 2004 +0000
+++ b/roundup/cgi/templating.py Sat May 15 03:53:43 2004 +0000
@@ -671,7 +671,7 @@
         Also sneak in the lastactivity and action hidden elements.
         """
         return self.input(type="hidden", name="@lastactivity",
-            value=self.activity) + '\n' + \
+            value=self.activity.local(0)) + '\n' + \
             self.input(type="hidden", name="@action", value="edit") +
'\n' + 
             self.input(type="submit", name="submit", value=label)

Before this patch, the lastNodeActivity was calculated using the
.local(0) value (setting it behind by 22 seconds) while the value for
@lastactivity in the templating class was not localized. So the same
time with two different corrections could have produced the problem.

In any case, I tested using:

  TZ=right/EST5EDT ./demo.py

and the values provided by the lastuseractivity value from templating
and the lastNodeActivity value have the same value and
roundup/cgi/actions.py:EditItemAction::detectCollision()
passes allowing me to edit the properties on the issue.

Closing as works for me.

(Note the timeline for this issue and the patch is all screwed up. The
patch went in before the 0.7.9 release and before this ticket was
opened. Maybe a problem with SF to this tracker conversion?)