Chronological Ordering of Nodes with the Same Timestamp

In "Tk label width to fit in text area", when viewed as "Replies are listed 'Oldest First'.", there are two nodes, listed in the following order, with these title bars:

Re: TK LABEL WIDTH TO FIT IN TEXT AREA [id://1199162]
by Anonymous Monk on Sep 12, 2017 at 14:35 AEST
...
Re: TK LABEL WIDTH TO FIT IN TEXT AREA [id://1199161]
by Anonymous Monk on Sep 12, 2017 at 14:35 AEST
...
[download]

Everything about these two nodes is identical except for the node IDs. [In fact, #1199162 had been considered for reaping because it's a duplicate: that may have happened by the time you read this.]

Anyway, on the basis that #1199161 was created before #1199162, #1199161 should be displayed first, i.e. the current order reversed.

As I've no idea of the code behind this, I can really only guess, but perhaps where the timestamps are identical, something akin to this could be added to the current sort functionality:

... || $a->{node_id} <=> $b->{node_id}
[download]

— Ken

Comment on Chronological Ordering of Nodes with the Same Timestamp Select or Download Code

Replies are listed 'Best First'.
Re: Chronological Ordering of Nodes with the Same Timestamp by choroba (Cardinal) on Sep 12, 2017 at 08:32 UTC
My pmdev skills are still very limited, by I guess the related code is: `my $orderby = $VARS->{notesortorder} \|\| $settings->{orderby} \|\| "createtime";` [download] The $orderby is later used in an ORDER BY clause in SQL. I don't know how to check the database yet. ($q=q:Sq=~/;[c](.)(.)/;chr(-\|\|-\|5+lengthSq)`"S\|oS2"`map{chr \|+ord }map{substrSq`S_+\|`\|}3E\|-\|`7**2-3:)=~y+S\|`+$1,++print+eval$q,q,a, [download]	[reply] [d/l] [select]
Re^2: Chronological Ordering of Nodes with the Same Timestamp by kcott (Archbishop) on Sep 12, 2017 at 09:26 UTC
G'day choroba, Thanks for looking. "My pmdev skills are still very limited" It's all relative. Mine are non-existent, so you have a huge a head-start on me. :-) — Ken	[reply]
Re: Chronological Ordering of Nodes with the Same Timestamp by QM (Parson) on Sep 12, 2017 at 08:05 UTC
`... \|\| $a->{node_id} <=> $b->{node_id}` [download] Just curious...do you have any evidence or suspicion that the sort is intentionally reversed? Ala: `... \|\| $b->{node_id} <=> $a->{node_id}` [download] -QM -- Quantum Mechanics: The dreams stuff is made of	[reply] [d/l] [select]
Re^2: Chronological Ordering of Nodes with the Same Timestamp by kcott (Archbishop) on Sep 12, 2017 at 08:22 UTC
G'day QM, "Just curious...do you have any evidence or suspicion that the sort is intentionally reversed?" No. I have neither evidence nor suspicion of that. As stated: "I've no idea of the code behind this". That was merely intended to suggest, in a Perlish way, that when there's no inherent ordering with whatever criteria is currently being used, ordering by node ID be used. It was in no way intended to be any sort of patch; just a rough suggestion: "something akin to this ...". — Ken	[reply]
Re: Chronological Ordering of Nodes with the Same Timestamp by RonW (Parson) on Sep 13, 2017 at 20:42 UTC
The underlying timestamp might not be equal. The database underlying the "Everything Engine" framework that PM rests on very likely stores time values at a higher resolution than traditional "Unix Time", as reported by time(). Under, for example, Linux, clock_gettime() reports time in nanoseconds.	[reply]
Re^2: Chronological Ordering of Nodes with the Same Timestamp by kcott (Archbishop) on Sep 14, 2017 at 07:09 UTC
G'day RonW, I did consider a number of potential issues, including that one; however, they're all just guesswork on my part. The underlying problem is that `#1199161` appeared after `#1199162`: my expectation was for the reverse order. [It appears from ++jdporter's response, that the createtime* was the same for both. I don't know how that specifically relates to timestamp.]* — Ken	[reply] [d/l] [select]
Re^3: Chronological Ordering of Nodes with the Same Timestamp by RonW (Parson) on Sep 14, 2017 at 22:11 UTC
I would presume createtime is the time stamp of the node's creation. Historically, files in Unix, and derived systems, had 3 time stamps: createtime, modtime and accesstime, referring to when a file was created, last modified and last accessed. Even when storing the nodes in a database, those names could be used as the corresponding field names. Also, it's quite possible for those fields to be auto-filled when a node record is created, updated or accessed. It may be that the database engine actually stores a higher resolution value, internally, than is made available to the program code using the database's API. Therefore, the ORDER_BY modifier to the SELECT operation may be using a higher resolution time stamp value. Also, it's possible that behavior similar to `for (keys %hash)` is occurring. If that is the case, then maybe changing: `ORDER_BY('createtime')` to: `ORDER_BY('createtime', 'nodeid')` would give the result you expected. (Assuming, of course, the database engine supports that.)	[reply] [d/l] [select]
Re: Chronological Ordering of Nodes with the Same Timestamp by jdporter (Paladin) on Sep 13, 2017 at 21:58 UTC
This is a good request. (The two nodes in your example had the same createtime, in fact.) I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.	[reply]
Re^2: Chronological Ordering of Nodes with the Same Timestamp by kcott (Archbishop) on Sep 14, 2017 at 07:17 UTC
G'day jdporter, ++ Thanks for the feedback. I don't imagine this has a high priority; but, when addressed, I wouldn't mind hearing about whatever fix was necessary. — Ken	[reply]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks