After much fooling about and finding all sorts of other 3rd party components make the same mistake I discovered this was a GregorianCalendar mistake.
Since this period isn't covered by the Gregorian Calendar it's out by up to 11 days in 1753.
This must be a bug as the compliance with this standard http://www.w3.org/TR/xmlschema-2/ states that:
"Each such object also has one decimal-valued method or computed property, timeOnTimeline, whose value is always a decimal number; the values are dimensioned in seconds, the integer 0 is 0001-01-01T00:00:00"
Only other dattime representations use "Gregorian algorithm as modified for leap-seconds"
So I assume that the DatatypeConverter.parseDateTime() method should not be using the Gregorian algorithm.
I don't follow your logic about it being a GregorianCalendar mistake. The 11 days in 1753 are handled correctly by GregorianCalendar as per its Javadoc, and they don't have anything to do with this problem anyway as you aren't out by 11 days. The Javadoc also states 'However, dates obtained using GregorianCalendar are historically accurate only from March 1, 4 AD onward'. So you can't represent it as a GregorianCalendar problem, because it is out of its domain. DatatypeConverter, yes.
You're half right. It's not a GregorianCalendar calendar problem as such, but it is associated with this.
If I run this method on the date "1753-01-01T00:00:00.000" it is 11 days out.
The problem only occurs when using the timeInMillis constructor which makes sense in this context.
Time in milliseconds since 0001-01-01 is different depending on if it's calculated in Gregorian or Julian standards.
By definition Gregorian dates are continuous, but in 1753, 11 days were removed from September so it's different.
In contrast, If I calculate the current date in the Julian standard, it's about 11 days different.
I just think that the XML Parser should conform to the standard and give an accurate date no matter if it's before or after epoc.
I have a work around. I parse the date myself and break it up into the constituent parts then construct a Calendar with those parts and add the milliseconds.
Perhaps the parser should do the same?