[Zope] y2kbug - bobobase_modification_time one day back

[Wolfgang Strobl]

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