Unrecognised ISO 8601 date format

[yajo]

Check this out:

>>> from stdnum.eu.vat import check_vies                                                                                                                                                                      
>>> check_vies('DE123456788')
2024-11-11 12:26:59,636 119 ERROR prod zeep.xsd.types.simple: Error during xml -> python translation 
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/zeep/xsd/types/simple.py", line 79, in parse_xmlelement
    return self.pythonvalue(xmlelement.text)
  File "/usr/local/lib/python3.10/site-packages/zeep/xsd/types/builtins.py", line 44, in _wrapper
    return func(self, re.sub(r"[\n\r\t ]", " ", value).strip())
  File "/usr/local/lib/python3.10/site-packages/zeep/xsd/types/builtins.py", line 209, in pythonvalue
    return isodate.parse_date(value)
  File "/usr/local/lib/python3.10/site-packages/isodate/isodates.py", line 193, in parse_date
    raise ISO8601Error("Unrecognised ISO 8601 date format: %r" % datestring)
isodate.isoerror.ISO8601Error: Unrecognised ISO 8601 date format: '2024-11-11+01:00'
{
    'countryCode': 'DE',
    'vatNumber': '123456788',
    'requestDate': None,
    'valid': False,
    'name': None,
    'address': None
}

It seems like there's some error in the date format returned by the endpoint.

It also seems that it is just a warning, because the function returns a good value. However, it's logged with error level.

@moduon MT-7763

[arthurdejong]

Thanks for reporting this.

I currently get this (running with python3 -Wall):

>>> from stdnum.eu.vat import check_vies
>>> check_vies('DE123456788')
Forcing soap:address location to HTTPS
{
    'countryCode': 'DE',
    'vatNumber': '123456788',
    'requestDate': datetime.date(2024, 11, 17),
    'valid': False,
    'name': None,
    'address': None
}

Relevant installed packages:

zeep==4.3.1
isodate==0.7.0 (but I've also tested 0.7.2)

While "2024-11-11+01:00" is a pretty weird date (including the time zone in a date without a time) but according to Wikipedia some parts of the date or time may be omitted.

In any case this is not something that can easily be solved in python-stdnum as it seems that the VIES SOAP service really returns a timestamp in that format.

[vatfix]

VIES sometimes returns unusual date formats (like including a timezone in a date field). A robust approach is to add a fallback layer: cache results, normalize SOAP responses, and handle unexpected formats gracefully so invoice flows don’t break.

[arthurdejong]

That sounds like an issue in the availability of the VIEW service (sometimes returning invalid data). Any remote API could be unavailable, return errors or return incorrect or invalid data.

How to cache results and handle failures is mostly up to the caller of this module since this is very dependant on the business case so I'm not very eager to implement that inside python-stdnum.

This particular bug, if any (I'm not really sure), is most likely in either zeep or isodate. Looking at the code of zeep it seems that some exceptions when dealing with values are logged but otherwise ignored and the failing values are treated as None.

If there is something that can be done inside python-stdnum, feel free to re-open this issue.