4 ms·

It’s a mistake to use timestamp for sorting versions instead of revision_id imo

by pharmakom 3y ago

steve_adams_86 3y ago
What case would you make for using revision_id?
- zambal 3y ago
  I'm not OP, but I can at least give an argument against using a timestamp for sorting versions: for various reasons system time is not guaranteed to be monotonic, which can result in cases where newer versions would be sorted before older versions. See https://www.erlang.org/doc/apps/erts/time_correction.html#introduction https://www.erlang.org/doc/apps/erts/time_correction.html#in... for more info. It's about time handling in the Erlang run-time system, but the issue it describes is universal. And having an Erlang background, I would say timestamps are also tricky in the context of distributed systems.
  - steve_adams_86 3y ago
    This is great, thank you. I’d never considered using time stamps like this before which is why I was curious, but I suppose now I can continue not using them slightly more confidently. What is programming really, but figuring out what not to do.
- nine_k 3y ago
  E.g. timestamps may (slightly) differ if the updates occur in different transactions, while the revision ID is likely passed around, and is easier to correlate. This is relatively rare though.
  - steve_adams_86 3y ago
    It does seem like it would be rare, but it’s a valid concern. You can arguably gain any insights that time stamps offer by including them as metadata or in an audit log, right? I find date and time data so difficult to work with that I typically avoid using it for anything important unless absolutely necessary.
- whoisthemachine 3y ago
  Evergreen article that neatly lists the problems with time (not just as a version key): https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...
- pharmakom 3y ago
  Total ordering. Database guarantees monotonicity.

It’s a mistake to use timestamp for sorting versions instead of revision_id imo

steve_adams_86 3y ago

What case would you make for using revision_id?

zambal 3y ago
I'm not OP, but I can at least give an argument against using a timestamp for sorting versions: for various reasons system time is not guaranteed to be monotonic, which can result in cases where newer versions would be sorted before older versions. See https://www.erlang.org/doc/apps/erts/time_correction.html#introduction https://www.erlang.org/doc/apps/erts/time_correction.html#in... for more info. It's about time handling in the Erlang run-time system, but the issue it describes is universal. And having an Erlang background, I would say timestamps are also tricky in the context of distributed systems.
- steve_adams_86 3y ago
  This is great, thank you. I’d never considered using time stamps like this before which is why I was curious, but I suppose now I can continue not using them slightly more confidently. What is programming really, but figuring out what not to do.
nine_k 3y ago
E.g. timestamps may (slightly) differ if the updates occur in different transactions, while the revision ID is likely passed around, and is easier to correlate. This is relatively rare though.
- steve_adams_86 3y ago
  It does seem like it would be rare, but it’s a valid concern. You can arguably gain any insights that time stamps offer by including them as metadata or in an audit log, right? I find date and time data so difficult to work with that I typically avoid using it for anything important unless absolutely necessary.
whoisthemachine 3y ago
Evergreen article that neatly lists the problems with time (not just as a version key): https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...
pharmakom 3y ago
Total ordering. Database guarantees monotonicity.