Project

Profile

Help

Patch #1417

closed

Newly implemented / re-implemented EXSLT date-time functions

Added by Anonymous almost 15 years ago. Updated almost 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Internals
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Legacy ID:
sf-2782850
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

SourceForge user: joefenton

Created new implementations of the following EXSLT date-time functions:

add

difference

seconds

Re-implemented the following functions to improve correspondence with the EXSLT spec

(mostly returning empty strings or NaN when the input is not in a correct date/time format):

date

year

day-in-month


Files

dateTime.diff (9.56 KB) dateTime.diff Anonymous, 2009-04-28 13:34
dateTime.diff (9.56 KB) dateTime.diff Anonymous, 2009-04-29 10:38
test.zip (9.56 KB) test.zip Anonymous, 2009-04-29 10:39
test.zip (9.56 KB) test.zip Anonymous, 2009-04-29 10:48
Actions #1

Updated by Anonymous almost 15 years ago

SourceForge user: mhkay

Thanks.

A few points:

(a) I can't say I'm happy with the dependency on a com.sun.org.apache class. Are you sure this is present in every JVM, e.g. in the OpenJDK library? Is there any reason you can't use Saxon's own implementation of XMLGregorianCalendar instead?

(b) Would you be happy to sign a release agreement confirming (on behalf of yourself and your employer) that you agree to release this code under MPL?

(c) Could you supply your test cases?

Actions #2

Updated by Anonymous almost 15 years ago

SourceForge user: nobody

Thanks for your quick response.

(a) We've removed this explicit dependency by using javax.xml.datatype.DatatypeFactory.newInstance() rather than a particular implementation of DatatypeFactory. A new patch is attached.

(b) That'll be fine.

(c) Attached will be a set of inputs, control files and a JUnit test class in a zip file. We couldn't find an existing test framework into which we could place these - please direct us to such a framework if it is available.

Actions #3

Updated by Anonymous almost 15 years ago

SourceForge user: mhkay

I've integrated the code and the tests. (Now I just need your signoff!) I converted the tests to run in my test framework and to deliver reproducible results (basically by comparing the result of the EXSLT date() with the XSLT 2.0 current-date()). I also ran my regression tests - three of them delivered different results and I'm satisfied that the new results are correct.

The code relies heavily on JDK 1.5 but you're in luck because I've essentially already decided that the next Saxon release will no longer support JDK 1.4.

Having said that, I'd feel more comfortable supporting this code if it were built on the Saxon implementation of the date/time data types in XSD, rather than the Sun/Apache implementation. Don't be disappointed if you find one day that I've rewritten it.

Actions #4

Updated by Anonymous almost 15 years ago

SourceForge user: mhkay

The supplied test for day-in-month('--04-31Z') gives 31, I believe the correct answer is NaN because this is not a valid lexical representation of a gYearMonth. The XSD 1.1 spec is much more explicit on this point, but it's only a clarification, not a substantive change.

I have recoded the relevant method to use the Saxon date/time classes rather than the Sun/Apache implementation, which results in this error being caught.

Actions #5

Updated by Anonymous almost 15 years ago

SourceForge user: mhkay

The EXSLT specification for difference() doesn't say much about how timezones are handled. It's not even clear as to whether the inputs can have a timezone or not. I've decided to follow XPath 2.0 and make the timezone optional, using the implicit timezone where necessary. I've recoded the logic to use the underlying Saxon date/time classes. The only effect on the supplied tests is that a zero-length yearMonthDuration displays as P0M rather than P0Y. This is the correct canonical representation (see http://www.w3.org/TR/xpath-functions/#dt-yearMonthDuration, section 10.3.1.3).

Actions #6

Updated by Anonymous almost 15 years ago

SourceForge user: mhkay

My reading of the spec is that date:difference('2000Z', '2001-01-02Z') should be P1Y1M. I believe your test result of P1Y is incorrect. Agreed, the spec is hardly very precise on the point.

Actions #7

Updated by Anonymous almost 15 years ago

SourceForge user: mhkay

My reading of the spec is that date:difference('2000Z', '2001-01-02Z')

should be P1Y1M.

Sorry, I missed the bit about the more specific being converted to the less specific (well, it's actually garbled in the spec, but that's what it means!). So P1Y is correct.

Only other changes I needed to make were to use canonical form for durations such as P1DT0S - should be simply P1D.

Actions #8

Updated by Michael Kay almost 11 years ago

  • Status changed from New to Resolved

Please register to edit this issue

Also available in: Atom PDF