This is all from the RTC Java API perspective, not the GUI.

For most cases, it seemed to be pretty reliable to use IChangeSet.getLastChangeDate() timestamp to determine between two given IFileItem objects which one was "newer".  However, we recently stumbled upon a case where this is not true.

1. RTC allows an older changeset to be delivered after a newer one, even if the same part was changed in both and the older changeset has the newer version of the part (same UUID) without requiring any merges (this can happen where the newer changeset did a conflict Resolve that uses an older version of the part that the older changeset had already made additional changes to...e.g. newer changeset, delivered first, uses version ID 5, and older changeset delivered second has version ID 6 that was based on 5)

2. a newer changeset might have an older version ID (when Resolve With Proposed is used and the incoming/older part has a lower-numbered version ID than one I already have in a Completed changeset in my workspace)

How on earth does one reliably know, give two IFileItem objects and their associated IChange/IChangeSet objects, which is newer according to RTC's history?  Sometimes the changeset lastChangeDate tells you, sometimes the version ID does, but neither is reliable.