This ist a typical Y2K bug, located in the module TimpeStamp.c, as I suspected earlier. Since nobody followed my hint from earlier this day so far, I took the opportunity to dig a little deeper, learning how to build and replace a python extension on the way. Given how little documentation there is, I don't claim having understood anything about, but noticing that the function static double TimeStamp_abst(int y, int mo, int d, int m, int s) gets called with y=100 (not 2000), changing the leap yar calculation l = y%4==0 && (y%100 != 0 || y%400==0); to l = y%4==0 && (y%100 != 0 || (y+1900)%400==0); in that function fixed the problem on my system. DTML Document at /y2k / t <dtml-var standard_html_header> <h2><dtml-var title_or_id></h2> <p> This is the <dtml-var id> Document. </p> <dtml-var "bobobase_modification_time()"><br> <dtml-var "_.DateTime()"> <dtml-var standard_html_footer> renders as This is the t Document. 2000/03/02 23:13:8.393 GMT+1 2000/03/02 23:13:54.619 GMT+1 now. The complete function from ZODB/TimeStamp.c in context: -------------------------------------------------------- static double TimeStamp_abst(int y, int mo, int d, int m, int s) { int l; l = y%4==0 && (y%100 != 0 || (y+1900)%400==0); // y2kfix ws 2000-03-02 // was l = y%4==0 && (y%100 != 0 || y%400==0); return (TimeStamp_yad(y)+ joff[l][mo]+d)*86400 + m*60 + s; } -------------------------------------------------------- Hope this hilft. :-} ------- End of forwarded message ------- -- Wolfgang Strobl