I recently encountered a group that would not stay renamed or deleted in a sync environment, but behaved normally when used in a standalone environment. When I exported the database to xml format I discovered the the dates associated with this group were far in the future. They look a bit like they might be boundary dates. The database has been in constant use for 3+ years so I have no idea when this occurred.
Actually 2999-12-29T07:59:59Z seems to be a very popular date in the database.
In KeePass 1.x the date 2999-12-28 23:59:59 is used to indicate either 'unknown date' or 'never expires'. KeePass 2.x doesn't use this approach. I guess you have moved from KeePass 1.x to 2.x and thus these dates got imported.
Theoretically the creation and last modification dates should never be set to the special 2999 date; thus this indicates a problem in KeePass 1.x (in the past). I've looked at the time code in 1.x again, but couldn't find any problem (dates seem to be set and updated correctly); I guess the problem was already fixed a long time ago.
Anyway, as these dates are in your 2.x database now, we need a solution here, too. I think a valid solution is to reinterpret the special 2999 date as a date lying in the past (this works, because as soon as you modify a group in today's 1.x or 2.x release, the group modification time gets updated correctly and will be newer than the reinterpreted 2999 date). I've implemented this now.
Here's the latest development snapshot for testing:
Thanks and best regards,
The patch worked perfectly!