POST request to modify timestamp does not respect defined format

[ghost]

What is the bug or the crash?

When inserting or updating a feature through WFS-T connection, field with defined timestamp format is not respected by the sent POST request.

Steps to reproduce the issue

1. Open WFS-T connection
2. Specify a timestamp field as following:
   
3. Create a new feature, and record the sent POST request
4. Check the sent POST request - timestamp format has changed into following:
   `yyyy-MM-ddTHH:mm:ss.sssZ'

Versions

QGIS version
3.20.1-Odense
QGIS code revision
1c3c5cd
Qt version
5.15.2
Python version
3.9.5
GDAL/OGR version
3.3.1
PROJ version
8.1.0
EPSG Registry database version
v10.018 (2021-04-02)
GEOS version
3.9.1-CAPI-1.14.2
SQLite version
3.35.2
PDAL version
2.3.0
PostgreSQL client version
13.0
SpatiaLite version
5.0.1
QWT version
6.1.3
QScintilla2 version
2.11.5
OS version
Windows 10 Version 2009

Active Python plugins
coordinate_capture
nominatim
db_manager
MetaSearch
processing

Supported QGIS version

• I'm running a supported QGIS version according to the roadmap.

New profile

• I tried with a new QGIS profile

Additional context

No response

[gioman]

hrough WFS-T connection

@geeneric regardless of the server or this is specific to QGIS Server?

[ghost]

hrough WFS-T connection

@geeneric regardless of the server or this is specific to QGIS Server?

WFS-T was served by Deegree. However, to me this seems specific to QGIS and not the WFS-T server.

[gioman]

to me this seems specific to QGIS and not the WFS-T server.

@geeneric have you tried with another backend?

[ghost]

to me this seems specific to QGIS and not the WFS-T server.

@geeneric have you tried with another backend?

No, I have not.

[rouault]

I'd be tempted to close that as invalid / wontfix.

• What goes on the "wire" in a WFS-T exchange is bound by the constraints of the XML format. If the format that you would have specified wouldn't be compatible of ISO8601, then it would not be possible to honour it anyway
• And technically, if we wanted to honour it, that would goes against the design of QGIS internals. A WFS provider object doesn't know to which layer it belongs to (and it could potentially be created without a supporting layer). I guess we could probably get the default QgsProject object, iterate through the layer and see to which we belong too, but that goes against the design.

@elpaso any opinion ?

[elpaso]

I'd be tempted to close that as invalid / wontfix.

* What goes on the "wire" in a WFS-T exchange is bound by the constraints of the XML format. If the format that you would have specified wouldn't be compatible of ISO8601, then it would not be possible to honour it anyway

* And technically, if we wanted to honour it, that would goes against the design of QGIS internals. A WFS provider object doesn't know to which layer it belongs to (and it could potentially be created without a supporting layer). I guess we could probably get the default QgsProject object, iterate through the layer and see to which we belong too, but that goes against the design.

@elpaso any opinion ?

I was thinking exactly the same.