Message from C, C++ discussions

November 2019

— If you make a database, you need to use a steady time, unix time can go backwards and forward depending on leap seconds

Message permanent page

— 

If a database uses unix timestamping, it is not consistent on operations done during a leap second if it ever stringifies time

— This is from the specs of a database management system I am working on, note what time may look like in a distributed system

The time is directed by the coordination server. Each server must synchronize to that time.

The time is never guaranteed to be the real time, but it is guaranteed that any time query return value will be strictly greater than the highest recorded time of the server. When the system is running in normal and degraded state, the unit of the subtraction of timestamps is nanoseconds, else it is undefined.

Message permanent page

— Oh okay,
tbh, we should just come up with a better solution to get time into a number

— For a database, the only important thing about time is that
1/ simultaneity doesn't exist
2/ time is steady

Message permanent page

— TAI and GPS time kinda solve that

— But you cannot rely a lot on time unless you own an atomic clock or a gps clock and networking hardware capable of a PTP synchronization

Message permanent page

— The perfect solution to everything, binary time, "will it happen?" or "did it happen?"

— It may be hard to realize, but the time light takes to go 1km is enough to complete a trading transaction in a financial quotation engine

Message permanent page

— Just by having a 2m DVI cable makes it impossible for your computer to display nanosecond accurate time

Message permanent page

— It will always be off by at least 6ns, the time needed to go through that cable

— I cannot uphold any time constraints in my database engine except the following: time goes forward