A valid SOAP message with <urn:timeStamp>9999-11-31T23:59:59.9999999</urn:timeStamp> in a xs:dateTime field return '9999-12-31 23:59:59,1000' is not a valid date and time from a Delphi application with this SOAP response:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>'9999-12-31 23:59:59,1000' is not a valid date and time</faultstring>
<faultactor/>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The reason is this exception:
exception class EConvertError with message ''9999-12-31 23:59:59,1000' is not a valid date and time'.
This is from a .NET based test case passing in timeStamp = DateTime.MaxValuewhich is handled perfectly fine by other SOAP web services tested.
I know about different resolutions of time stamps, but would never expect the 999.9999 milliseconds to be rounded up to 1000 as it is always safer to truncated away from an upper limit.
A test using Soap UI [WayBack] with this parameter finally worked (max 3 digits second fraction):
<urn:timeStamp>9999-12-31T23:59:59.999</urn:timeStamp>
The true origin of problem is in this method in the Soap.XSBuiltIns unit which has been unchanged since at least Delphi 7:
function TXSBaseTime.GetMilliSecond: Word; begin Result := Round(FractionalSeconds*1000); end;
The problem exposed itself because as of Delphi XE6 the core of function TXSBaseCustomDateTime.GetAsDateTime piece was changed from
Result := EncodeDateTime(Year, Month, Day, Hour, Minute, Second, 0);
to
Result := EncodeDateTime(Year, Month, Day, Hour, Minute, Second, Millisecond);
A combination of lack of test cases and understanding XML specifications failed to reveal this bug.
The standards specify (among others):
'.' s+ (if present) represents the fractional seconds;
The above is not limiting the amount of digits, not talking about milliseconds either.All ·minimally conforming· processors ·must· support year values with a minimum of 4 digits (i.e., YYYY) and a minimum fractional second precision of milliseconds or three decimal digits (i.e. s.sss). However, ·minimally conforming· processors ·may· set an application-defined limit on the maximum number of digits they are prepared to support in these two cases, in which case that application-defined maximum number ·must· be clearly documented.
Delphi not only limits the fractional second precission, it changes the limit over time and does not document the limit. Three strikes…s -- represents a digit used in the time element "second". The two digits in a ss format can have values from 0 to 60. In the formats described in this specification the whole number of seconds ·may· be followed by decimal seconds to an arbitrary level of precision. This is represented in the picture by "ss.sss". A value of 60 or more is allowed only in the case of leap seconds.
Given buggy the fractional second handling through milliseconds, the leap second handling is ripe for a test case as well.
Strictly speaking, a value of 60 or more is not sensible unless the month and day could represent March 31, June 30, September 30, or December 31 in UTC. Because the leap second is added or subtracted as the last second of the day in UTC time, the long (or short) minute could occur at other times in local time. In cases where the leap second is used with an inappropriate month and day it, and any fractional seconds, should considered as added or subtracted from the following minute.
The reproduction is quite simple:
