function relation_save changed time can be 1 second before created time.

The changed time stamp is set by invoking time(), several lines of code above the setting of the created time by calling time() a second time. What should happen is a time stamp is fetched and is then used for both create and changed times. Both these values should be forced to be identical for new saves. Neither should be allowed to have even the remotest possibility of the create date being after or before the changed date (for new relations).

One Possible Solution:

$relation->created = $relation->changed;

This solution avoids a temporary variable to hold the time stamp. While it reads awkward, it does the job.

Justification Detail:

Having the changed date before the create date is certainly a corruption of the data. How could a relation have been changed before it was created? Testing for "new" relation, that is one that is unchanged, would fail in the rare case the function time() invokations returned different values.

Having the changed date after the create date gives the appearance that a new relation has been modified, which would not be true for a new relation. A test that the two times were the same would fail in a rare case.

This bug was determined by a source code review, not by actually testing in a live site.

Best Practices for fetching a time stamp for use inside a function is always fetch the time with the first line of code, so it's more accurate, and use that one time stamp in all required fields, to ensure it is the same value, to avoid the appearance of data corruption, and to allow downstream conditional statements an accurate way of testing for time stamps that should be identical.

Hope this helps, a rare case.