It appears that the code that computes the current datetime in libexslt/date.c is incorrectly computing the current timezone offset around month boundaries.  Specifically, when I am in EDT and my localtime is in September and GMT is in October, it returns a time that is incorrect by more than 24 hours.  Here is the posting I sent to the mailing list which includes specific instructions for reproducing the problem.

On Sun, Oct 01, 2006 at 08:07:57AM -0400, Christopher R. Palmer wrote:
> > Last night, date:seconds() started returning invalid values. To test I 
> > created a simple stylesheet that simply printed
> > 
> > <xsl:value-of select="date:seconds()"/>
> > 
> > It printed a time from the day before.  Coincidentally, this started 
> > happening after 8pm EDT which would be when my time was in September and 
> > the GM time was in October.  The code (line 791 of 1.1.17) looks pretty 
> > suspicious to me:
> > 
> >      ret->value.date.tzo = (((ret->value.date.day * 1440) +
> >                              (ret->value.date.hour * 60) +
> >                               ret->value.date.min) -
> >                             ((gmTm->tm_mday * 1440) + (gmTm->tm_hour * 60) +
> >                               gmTm->tm_min));
> > 
> > which seems to be computing the seconds between localtime and gmtime.  With 
> > no mention of month I can't see how that is right...  I assume something 
> > similar but worse will happen at the end of the year.
> > 
> > I can reproduce this problem by adding
> > 
> > secs = 1159664596;
> > 
> > immediately after the call to time(NULL) in exsltDateCurrent while running 
> > the software on a machine in EDT.  When I do this, the value of tzo is 2000 
> > while the correct value should be -240.