Looking at the LJ source code: it appears that journal entries have two separate database fields for the user-supplied datestamp. "eventtime" is an ordinary date+time field, and "revttime" appears to be a "reverse" event time, stored as the number of seconds between the given date and (time_t)231-1. It looks as if "eventtime" is used to display the date stamp, but "revttime" is used for sorting (with the effect that things sort in reverse order).
Quite why this denormalisation is necessary, and it isn't sufficient to use the DESC keyword in the SELECT statement that retrieves recent journal entries, I have no idea whatsoever. However, it suggests that a strong possibility for this odd behaviour might be that the "eventtime" and "revttime" fields might have managed to get out of sync with one another. Can't immediately see how, admittedly.
It looks as if they get reset simultaneously when you edit the entry's date; so you could try editing each entry to a different time and back, and see if that resets it to sanity.
(Source code references in case you want to check my reasoning: bin/upgrading/update-db-general.pl rev 1.173 line 853 is the table description containing the "revttime" field; cgi-bin/ljlib.pl rev 1.803 line 1439 sets the sort key to "revttime" while line 1505 uses "eventtime" as the displayed date; cgi-bin/ljprotocol.pl rev 1.269 line 1194 is the UPDATE statement that changes the two fields in parallel.)
I did edit them all and re-save to see if that sorted it, but I didn't think to alter the dates. I've just poked the odd one out back a minute, and it all makes sense now... ta.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2004-12-21 03:37 pm (UTC)(no subject)
Date: 2004-12-21 03:56 pm (UTC)eventtime" is an ordinary date+time field, and "revttime" appears to be a "reverse" event time, stored as the number of seconds between the given date and(time_t)231-1. It looks as if "eventtime" is used to display the date stamp, but "revttime" is used for sorting (with the effect that things sort in reverse order).Quite why this denormalisation is necessary, and it isn't sufficient to use the
DESCkeyword in theSELECTstatement that retrieves recent journal entries, I have no idea whatsoever. However, it suggests that a strong possibility for this odd behaviour might be that the "eventtime" and "revttime" fields might have managed to get out of sync with one another. Can't immediately see how, admittedly.It looks as if they get reset simultaneously when you edit the entry's date; so you could try editing each entry to a different time and back, and see if that resets it to sanity.
(Source code references in case you want to check my reasoning:
bin/upgrading/update-db-general.plrev 1.173 line 853 is the table description containing the "revttime" field;cgi-bin/ljlib.plrev 1.803 line 1439 sets the sort key to "revttime" while line 1505 uses "eventtime" as the displayed date;cgi-bin/ljprotocol.plrev 1.269 line 1194 is theUPDATEstatement that changes the two fields in parallel.)(no subject)
Date: 2004-12-21 05:12 pm (UTC)I did edit them all and re-save to see if that sorted it, but I didn't think to alter the dates. I've just poked the odd one out back a minute, and it all makes sense now... ta.