I need to transform a .NET DateTime
to an equivalent Java Calendar
representation.
The .NET DateTime
uses Ticks
Answering the 'why':
From the (decompiled - thanks dotPeek!) .NET 4 source code (comments are mine):
public static DateTime operator -(DateTime d, TimeSpan t)
{
//range checks
long internalTicks = d.InternalTicks;
long num = t._ticks;
if (internalTicks < num || internalTicks - 3155378975999999999L > num)
throw new ArgumentOutOfRangeException("t",
Environment.GetResourceString("ArgumentOutOfRange_DateArithmetic"));
else
//plain arithmetic using the Ticks property of the two dates.
return new DateTime((ulong) (internalTicks - num) | d.InternalKind);
}
So yeah, absolutely no special 'gregorian' treatment for DateTime operators.
About the 'how to fix':
I ended up using something along these lines: (pseudo-Java)
Calendar cal = new GregorianCalendar();
cal.set(dt.Year, dt.Month - 1 /*it's 0-based*/, dt.Day, dt.Hour, dt.Minute, dt.Second);
cal.set(Calendar.MILLISECOND, dt.Millisecond);
Surprisingly, no one has actually answered the question of why a "hole" exists in the Gregorian Calendar between October 4, 1582 and October 15, 1582. The interesting answer is in the history of the adoption of the Gregorian Calendar as a reform in 1582 to the Julian Calendar. See Wikipedia's article on Gregorian Calendar for details. The last paragraph in the History: Gregorian Reform paragraph states
- Gregory (Pope Gregory XIII) dropped 10 days to bring the calendar back into synchronisation with the seasons. Accordingly, when the new calendar was put in use, the error accumulated in the 13 centuries since the Council of Nicaea was corrected by a deletion of ten days. The Julian calendar day Thursday, 4 October 1582 was followed by the first day of the Gregorian calendar, Friday, 15 October 1582 (the cycle of weekdays was not affected).*
In effect, the dates from October 5, 1582 to October 14, 1582 do not exist in the Gregorian Calendar. I suspect that the .Net Framework uses a generalized formula and does not account for the difference when dealing with dates prior to October 15, 1582, whereas the Java library does account for it.
From the Java documentation:
[...] dates obtained using
GregorianCalendar
are historically accurate only from March 1, 4 AD onward, when modern Julian calendar rules were adopted
Considering your DateTime
subtraction, it's only a Ticks
difference, there is absolutely no notion of a specific calendar here. The implementation is basically return new TimeSpan(x.Ticks - y.Ticks)
.
You might be better at simply outputting then parsing an ISO-8061 date/time such as 0001-02-03T00:00:00Z
, which has no ambiguity, rather than relying on the internal representation.