Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Chronological Ordering of Nodes with the Same Timestamp

by RonW (Vicar)
on Sep 13, 2017 at 20:42 UTC ( #1199348=note: print w/replies, xml ) Need Help??


in reply to Chronological Ordering of Nodes with the Same Timestamp

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.

  • Comment on Re: Chronological Ordering of Nodes with the Same Timestamp

Replies are listed 'Best First'.
Re^2: Chronological Ordering of Nodes with the Same Timestamp
by kcott (Chancellor) 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

      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.)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1199348]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2017-12-14 23:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (414 votes). Check out past polls.

    Notices?