The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,284 other followers

Archive for September 6th, 2018

Delphi XE6 and up regression: “‘9999-12-31 23:59:59,1000’ is not a valid date and time” when passing a SOAP message with 9999-11-31T23:59:59.9999999; QC144171

Posted by jpluimers on 2018/09/06

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="" xmlns:xsd="" xmlns:xsi="" xmlns:SOAP-ENC="">
      <faultstring>'9999-12-31 23:59:59,1000' is not a valid date and time</faultstring>

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):


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;
  Result := Round(FractionalSeconds*1000);

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);


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:

Read the rest of this entry »

Posted in .NET, C#, Conference Topics, Conferences, Delphi, Development, Event, SOAP/WebServices, Software Development, XML, XML/XSD | Leave a Comment »

playing with IOT

Posted by jpluimers on 2018/09/06

Interesting stuff:

Open-source home automation platform running on Python 3. Track and control all devices at home and automate control. Installation in less than a minute.

Source: Home Assistant


@Dysan ‚ÄĘ 18 mei 2017 09:47

Ik doe dus een hoop met home-assistant ( en wat custom Python scripts/apis wat allemaal op een oude laptop met ubuntu draait (10w verbruik).

De Horizon Box specifiek gaat via Harmony Hub, kan via de standaard integratie of via eigen brouwsels. Lifx en Nest heeft standaard integratie met Google Home. Al heb ik voor Lifx zelf het een-en-ander geschreven in Python om bijvoorbeeld scenes op te slaan en op te roepen met voice commando’s, dat kan weer niet standaard. NS API gaat ook via die Python API en wat er terug gezegd wordt (in het Nederlands) gaat via home-assistant.

Het voordeel van zelf zoiets bouwen is dat ik alles makkelijkers aan elkaar kan knopen dan bijvoorbeeld via IFTTT en Stringify o.i.d.. Zo kan ik bijvoorbeeld “Hey Google, sexy time” roepen en dan veranderd mijn verlichting langzaam naar iets romantischers (denk rood/oranje/roze), speelt er een zwoel lounge muziekje op mijn Sonos van een samba share, gaat de tempratuur wat omhoog en gaat mijn tv aan naar het chromecast kanaal en speelt er van die zelfde samba share een mp4 met een haardvuurtje.

Vet cheesy, I know, ik moet er de eerste vrouw nog mee verrassen :P maar het was ook vooral als demo van wat ik allemaal kan aansturen, bedoeld als grapje voor vrienden etc.

Google voegt een notificatiefunctie toe aan zijn Home-speaker. Als gebruikers een belangrijk bericht krijgen, zullen de ledjes op de speaker de aandacht gaan trekken van de gebruiker. De speaker gaat vooralsnog niet uit zichzelf spreken.

Source: Home-speaker van Google krijgt notificatiefunctie – Beeld en geluid – Nieuws – Tweakers


Posted in Development, IoT Internet of Things, Network-and-equipment, Power User, Software Development | Leave a Comment »

Delphi – Defer defines the ‚Äúpostpone procedure‚ÄĚ pattern to execute code at the end of a method

Posted by jpluimers on 2018/09/06

Last year, I stumbled upon [WayBack] Defer defines the ‚Äúpostpone procedure‚ÄĚ pattern, this postpone should schedule a ‚Äúprocedure: TProc‚ÄĚ to run it after the end of the caller method… – Cesar Romero – Google+¬†that points to this repository:

Some people like this usage of the RAII pattern, but I do like it even though I do not use it very often. The implementation better than my TAnonymousMethodMemento in Delphi: a memento that executes any code at end of method for various reasons:

Now the documentation could use more English (some of it is in Portuguese).


Posted in Delphi, Development, Software Development | Leave a Comment »

%d bloggers like this: