On 22/10/13 23:27, Andy Seaborne wrote:
On 22/10/13 21:38, Altmann, Michael wrote:
It appears that jena does not handle dates that are in the range 00 to
999. When it generates the lexical form, it fails to pad the year to
4 digits, which leads to RDF parse problems.
This test, run against jena 1.7.3
public void testTwoDigitYear() {
Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, 77);
cal.set(Calendar.MONTH, 11);
cal.set(Calendar.DATE, 25);
XSDDateTime xdt = new XSDDateTime(cal);
LiteralLabel ll = LiteralLabelFactory.create(xdt, "",
XSDDatatype.XSDdateTime);
System.out.println("Note that the year has only two
digits: literal is "+ ll);
assertTrue(ll.isWellFormed());
}
produces
Note that the year has only two digits: literal is
77-12-25T21:32:55.66Z^^http://www.w3.org/2001/XMLSchema#dateTime
and then the assertion fails.
My guess is that the root cause is that the toString method of
XSDDateTime begins
public String toString() {
StringBuffer buff = new StringBuffer();
if ((mask & YEAR_MASK) != 0) {
buff.append(data[CY]);
} else {
buff.append("-");
}
and doesn't pad the data[CY] to four digits.
Michael Altmann
Michael,
Thanks for the bug report and details. I agree that toString() needs to
pad with zeros for years between -1000 and 1000.
I've created JENA-565 so it does not get lost.
https://issues.apache.org/jira/browse/JENA-565
Fixed in svn and next development build ...
If you need to retro-patch Jena 2.7.3 then the change is in
XSDDateTime.toString.
https://svn.apache.org/repos/asf/jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/datatypes/xsd/XSDDateTime.java
The source release is a fully buuldable system.
http://archive.apache.org/dist/jena/source/jena-2.7.3-source-release.zip
Andy
Andy