Possible bug in Frontier XML-RPC

[Dave Winer]

I'm putting together a simple XML-RPC client for JavaScript and testing it against a Frontier server.

I hit what looks like a bug in the Frontier implementation, believe it or not. 

I have a simple handler that returns a date value.

on simpleHandler () {

return (clock.now ());

This is what I get back.

<?xml version="1.0"?>

<methodResponse>

<params>

<param>

<value><dateTime.iso8601>20180522T12:04:29</dateTime.iso8601></value>

</param>

</params>

</methodResponse>

The value doesn't appear to conform to the iso 8601 format, and JavaScript's Date.parse () routine doesn't like it.

I would think that the kernel would use date.dateToIso8601String to return the value, but it gets the formatting right.

date.dateToIso8601String (clock.now ())

   «"2018-05-22T12:30:44-04:00"

It's not a big deal, because I can easily work around it. But perhaps something broke somewhere along the line?

Dave

[Jake Savin]

Hi Dave.

tl;dr: This is most likely a kernel-level bug either in system.verbs.builtins.xml.valToString, or in system.verbs.builtins.xml.coercions.frontierValueToTaggedText, and I don't know of an easy fix without working around the bug on the receiving end.

It looks like I wrote date.dateToIso8601String in 2003, which according to the examples on the W3C site seems to do the right thing: https://www.w3.org/TR/NOTE-datetime

Apparently betty.rpc.server doesn't use it, as it serializes to XML via xml.coercions.frontierValueToTaggedText which was originally implemented in script and then "kernelized" in 1999. The script version called through to xml.valToString to get the ISO-8601 version (in the case of a date), and presumably the kernelized version calls the kernel version of valToString also.

Not sure if this helps at all :-\

Cheers,
-Jake

Dave Winer

May 22, 2018 at 9:34 AM

--
You received this message because you are subscribed to the Google Groups "frontier-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to frontier-use...@googlegroups.com.
Visit this group at https://groups.google.com/group/frontier-user.
For more options, visit https://groups.google.com/d/optout.

[Dave Winer]

BTW, according to the Wikipedia page on this format --

https://en.wikipedia.org/wiki/ISO_8601 

The form used by Frontier described above is valid. 

Dave

 

[Dave Winer]

Now that I know that what Frontier is returning is correct, I was able to add a workaround in my JS code.

function parseDate (theString) {

var theDate = Date.parse (theString);

if (isNaN (theDate)) {

var datePart = stringNthField (theString, "T", 1);

var timePart = stringNthField (theString, "T", 2);

var year = stringMid (datePart, 1, 4);

var month = stringMid (datePart, 5, 2);

var day = stringMid (datePart, 7, 2);

theString = year + "-" + month + "-" + day + "T" + timePart;

theDate = Date.parse (theString);

}

return (theDate);

}

So to the extent that this is an issue, it's closed. ;-)

Dave