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.]
| [reply]
[d/l]
[select] |
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] |
