Re: [xslt] Troubles with the EXSLT date extensions

[cbozeman hiwaay net]

The main source of the problem is in _exsltDateDifference where the calculations 
of the days and seconds are performed independently. My attatched patch fixes 
that problem but it may not be particularly elegant. Igor you are correct about 
the formatting code not taking into account that both seconds and days are 
negative but I don't know that it is worth fixing; the plan was to incorporate 
the schema date/duration code once it becomes fully integrated into libxml and 
that will mean a lot of other changes.
As far as there being a similar problem in the schema code, I doubt it. The 
closest thing to a difference function is adding two dates which uses a very 
different alogorithm.
I have attached patches for date.c and difference.1.xml (to incorporate the 
bugs) but I don't know if I did the patch correctly. I don't have CVS access at 
work and my monitor at home died.
Feel free to make any changes you feel are necessary and I'll keep monitoring my 
email if you have any questions.

Charlie B.

PS. I haven't seen anything on the EXSLT web site concerning the odd September 
month so I agree with Daniel that we should ignore it.

Quoting Igor Zlatkovic <igor@stud.fh-frankfurt.de>:

> Hi there,
> 
> > > I'll now check where the wrong numbers, that is those which differ
> from
> the
> > > correct result by more than d * -1, come from. I suspect the problem
> to
> be
> > > some odd double->long conversion, or similar.
> >
> >   Okay, you're in control, feel free to commit of course !
> 
> A second glance has revealed that not the datatype conversion plagues
> us,
> but that the conversion of the duration to string is somewhat wrong,
> now
> that we corrected the xy order :-) Look:
> 
> Given these arguments:
>   x = 2002-01-01T23:59:59
>   y = 2002-01-02T00:00:00
> we can see that the difference is exactly one second. The relevant code
> in
> libexslt computes the difference between the two dates and two times
> separately, then it builds a sum of those differences. When it compares
> the
> dates, it discovers that there is one day difference. When it compares
> the
> times, it discovers the difference of -86339 sec. Adding these to each
> other, 1 day + (-86339 sec) = 86340 sec + (-86339 sec), yields a
> duration of
> one second. Still:
>   d = -P1DT23H59M59S
> which is wrong. The formatting function, exsltDateFormatDuration,
> wrongly
> assumes that the duration is negative if any one of the components
> (secs,
> days, months, years) is negative, then it makes all negative
> components
> positive and combines them. The truth is that these components must be
> combined with regard to their sign, so that one year and negative
> twelve
> months yield zero, for example. I'll fix that and hope all else will
> remain
> unbroken.. Charlie? :-)
> 
> The old cal utility on any Unix tells another story:
> 
>   [spell:~]$ cal 9 1752
>      September 1752
>   Su Mo Tu We Th Fr Sa
>          1  2 14 15 16
>   17 18 19 20 21 22 23
>   24 25 26 27 28 29 30
> 
> We can see that September 1752 in the gregorian calendar had few days
> less
> than it normally does. If the x and y lay on different sides of that
> year,
> our date:difference(x,y) will compute a wrong duration. Am I severly
> misguided in my understanding of the gregorian calendar and if I am
> not,
> shouldn't something be done here?
> 
> Ciao
> Igor
> 
> 
> 
> _______________________________________________
> xslt mailing list, project page http://xmlsoft.org/XSLT/
> xslt@gnome.org
> http://mail.gnome.org/mailman/listinfo/xslt
>

date.c-pat

difference.1.xml-pat