y2kbug - bobobase_modification_time one day back
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. :-} -- Wolfgang Strobl
Wolfgang Strobl wrote:
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.
People did report this bug elsewhere on the list. Apparently we're waiting until monday when Jim Fulton can take a look at this. They're pretty sure it's just a display problem and not something wrong with the object database, but they want to make sure and check with Jim. Regards, Martijn
On 3 Mar 00, at 21:00, Martijn Faassen wrote:
Wolfgang Strobl wrote:
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.
People did report this bug elsewhere on the list.
Of course. Some people suspected a "user error" at first, though. :-) Anyway, I wasn't reporting a bug anymore, I found the probable cause in the TimeStamp module, in the meantime, and reported that findings, and a way to fix it, here.
Apparently we're waiting until monday when Jim Fulton can take a look at this. They're pretty sure it's just a display problem and not something wrong with the object database, but they want to make sure and check with Jim.
Lets hope for the best. :-) PS: people have asked my for the modified TimeStamp module in (TimeStamp.pyd on my NT system) in private mail, but I'd prefer to have them wait for an "official" fix. Poking around in the object data base source isn't something to take lightly. -- mailto:Wolfgang.Strobl@gmd.de, ws@mystrobl.de or ws@mail.gmd.de
participants (2)
-
Martijn Faassen -
Wolfgang Strobl