The one thing that saddens me is that the clock is not the full first part of the UUID, so it's not a proxy for sorting by creation date. I often wonder why they did that, they must have done it on purpose.
On 11/25/17, Peter Da Silva <peter.dasi...@flightaware.com> wrote: >>> What about time resets to the epoch which are not restored, user time >>> changes, >> >> I know some systems at least increment the node each time a time change is >> detected. It will take 2^47 time changes to roll over. Since the node part >> is not relevant to SQLite, this is perfectly safe. > > Also, the UUID clock doesn't need to be the system clock, so you can simply > ignore backwards changes in the system clock (or maintain a common offset > that gets updated whenever a backwards change is detected in the system > clock). Over time this may trim a few decades off the 3000+ year life of the > format. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
