Hacker News Reader

Comment by pharmakom | Hacker News Reader

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

What case would you make for using revision_id?

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

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.

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.

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.

Evergreen article that neatly lists the problems with time (not just as a version key): https://infiniteundo.com/post/25326999628/falsehoods-program...

Total ordering. Database guarantees monotonicity.

Reply on news.ycombinator.com