MapInfo Pro

• MapInfo Pro version 15.2.4 (64-Bit) Release Build 502
• MapInfo Pro version 16.0.2 (64-Bit) Release Build 205
• Geoserver version 2.12.0 publishing WFS-T (WFS v1.0.0)

I refer to previous similar posts / references:

1. The following link is no longer available. To access this information, copy the title found in the url into the search tool on the top nav bar, or try searching for key words in the post. https://li360.pitneybowes.com/s/question/0D58000003pBvw5CAC/wfs-date-fields-not-displaying
2. The following link is no longer available. To access this information, copy the title found in the url into the search tool on the top nav bar, or try searching for key words in the post. https://li360.pitneybowes.com/s/article/Resolve-error-message-when-trying-to-edit-using-WFS-T-in-MapInfo-Pro-15-x-and-16-0

Behaviour for both MapInfo versions is identical:

1. WFS-T date fields display in browser and info windows no worries
2. Editing existing records - geometry, any attributes (including date fields) - data saves and refreshes perfectly
3. Create a new record (e.g. drawing a new geometry in the map layer, and then editing attributes) - save fails with java "Parsing failed" error - unable to proceed.
4. Copy-and-paste an existing record in its entirety - no changes - save fails with java "Parsing failed" error - unable to proceed.

Error Message Details

In all cases, the error message relates to date parsing - example shown:

java.lang.RuntimeException: Parsing failed for date_stamp: java.lang.IllegalArgumentException: Failed to parse date 20171214 at:

Parsing failed for date_stamp: java.lang.IllegalArgumentException: Failed to parse date 20171214 at:

Failed to parse date 20171214 at:

Same WFS Service Works in QGIS

Accessing the same WFS service using QGIS 2.18.7 - forcing WFS version 1.0.0 to match MapInfo - I can edit and add records as required.

I note that it is possible to invoke the same error message using QGIS. The date field must be formatted as YYYY-MM-DD or the same parsing problem occurs - example below:

       java.lang.RuntimeException: Parsing failed for date_stamp: java.lang.IllegalArgumentException: Failed to parse date 31/12/17 at:/12/17

Parsing failed for date_stamp: java.lang.IllegalArgumentException: Failed to parse date 31/12/17 at:/12/17

Failed to parse date 31/12/17 at:/12/17

I have been pushing forth on system and business process development work on the basis that WFS-T editing was fully supported (and functional) for versions: 12.5.2, 15.2.4, 16.0.2, as per the previous related thread (reference 1 at the top of this posting.) At the moment, this is an absolute show-stopper.

Please advise:

• Is there something I'm doing wrong?
• Is there something I can do differently (e.g. Geoserver config?)
• Is there a MapInfo Pro patch (or series of patches) in our immediate future which can address this problem?

I appreciate the assistance provided by this forum to date. I really need to call upon that assistance again, please.

I look forward to your replies!

Cheers,

David

Hi David

I'm wondering if the regional settings in any way is interfering with how the date gets passed to the service (it really shouldn't but...).

Any chance you can capture the update statement sent from MapInfo Pro to GeoServer, for example using Fiddler?

How is your short date formatting set in Windows Regional Settings? Is it set to YYYY-MM-DD? If not, could you try to change it to that format.

Thanks

Hi Peter,

I've got some Geoserver log excerpts to send you (via email, rather than open forum - I trust that's OK.) Can't use Fiddler in this environment, but I think the logs will show the same info anyway.

I really suspect we're in XML hell, actually - or possibly java hell - rather than date format land. Reasoning as follows:

1. Windows short date format is "DD/MM/YYYY" (with no way to change in locked-down SOE environment) - but the date format appearing in the XML transaction statements is "YYYYMMDD" as indicated in my original post. i.e. MapInfo browser displays dates as e.g. "15/12/2017" but the data sent via XML shows "20171215"
2. MapInfo updates work fine using "YYYYMMDD" data. It's just the inserts which fail - and I can demonstrate QGIS failing exactly the same way when attempting to insert "YYYYMMDD" date data, too. QGIS inserts succeed when the date format is changed to "YYYY-MM-DD".

Stand by for separate email with attachments. I look forward to any solutions on offer!

Cheers,

David

Thanks, David.

I have passed these onto Engineering

We'll keep you posted