The short answer is that the iCurrentDate of a "statement" (VDBE program) is "step stable" because it is reset to 0 each time that sqlite3_step is called on a statement. All accesses to iCurrentDate within that execution/step refer to the same iCurrentDate which is recorded the first time it is accessed in that execution/step. In my own private branch of the code I have a patch which only resets iCurrentDate to 0 on "initial entry" into the VDBE program (that is, when the program counter is 0) which will make iCurrentDate "statement stable", meaning that iCurrentDate is set first time it is accessed by the statement and iCurrentDate remains unchanging until the statement is reset, even across multiple calls to step. Making iCurrentDate "transaction stable" would require storing iCurrentDate in the connection context and adjusting the autocommit code to reset/clear the connection iCurrentDate at transaction end and the sqlite3StmtCurrentTime to use the connection iCurrentDate -- I have not looked into this and, although the changes are probably trivial, I do not think anyone has ever requested it -- I don't know if anyone has ever requested that iCurrentDate be "statement" stable rather than "step" stable. The patch I have installed follows and creates a new define SQLITE_NOW_STABILITY_STMT which causes iCurrentDate to be statement stable rather than step stable. ``` Index: src/vdbe.c ================================================================== --- src/vdbe.c +++ src/vdbe.c @@ -703,10 +703,13 @@ } assert( p->rc==SQLITE_OK || (p->rc&0xff)==SQLITE_BUSY ); testcase( p->rc!=SQLITE_OK ); p->rc = SQLITE_OK; assert( p->bIsReader || p->readOnly!=0 ); +#ifdef SQLITE_NOW_STABILITY_STMT // Only reset iCurrentDate at start of statement + if (p->pc == 0) +#endif p->iCurrentTime = 0; assert( p->explain==0 ); p->pResultSet = 0; db->busyHandler.nBusy = 0; if( AtomicLoad(&db->u1.isInterrupted) ) goto abort_due_to_interrupt; ```