[ZODB-Dev] Summertime -> Wintertime harmful?

[Tim Peters]

 [Andreas Jung]
>> Possibly a stupid question:

Nope, it's a good question!

>> Last night the European clocks switched back to winter-time. So the
>> ZODB might see multiple timestamps (and unordered transaction) from
>> transactions happened between 2am and 3am...just for curiosity: is
>> there a risk getting an inconsistent ZODB?

[Jim Fulton]
> No.
>
> First, ZODB time stamps are based on UTC time.

More precisely, they use Python's time.gmtime() to get the current time.
There have been "bugs" reported on the Python tracker from sysadmins crazy
enough to change their system config so that time.gmtime() doesn't actually
return UTC, but that shouldn't be a concern for sane users.

> Second, time-stamp skew doesn't lead to inconsistency.

Fleshing out a bit, ZODB uses time.gmtime() as a starting point, not
necessarily as its final timestamp.  When generating a new tid, if
time.gmtime() is <= the last tid generated, the last tid is incremented
instead (by a small number of nanoseconds).  So tids are always strictly
increasing, no matter how crazy the system clock gets.  Older versions of
ZODB had some obscure bugs in extreme cases of clock insanity, under which
it was possible for tids not to always increase, but no bugs of that sort
should remain.

It's still a bad idea to let the system clock be insane, and upon opening a
FileStorage ZODB logs a warning message if time appears to have "gone
backwards" at all, and a critical message if it appears to have gone
backwards by more than 30 minutes (but note that if the system clock "went
forward" in time, ZODB has no way to guess that).  tids in current ZODBs
will still be increasing, but there's a downside:  there are a _lot_ of
"small number of nanoseconds" in a second, so for as long as ZODB remains in
"increment the last tid by a small number of nanoseconds, because
time.gmtime() is crazy" mode, successive transactions will get timestamps
only a few nanoseconds apart.  This can wreak havoc with, e.g., forensic
analysis of database dumps, and with sane packing (if the last year's worth
of transactions all appear to have occurred in the same 1-second interval,
good luck guessing a useful pack-time argument).