Description
I think the handling of timezones in dates might be wrong. Previously, isodate was ignoring the timezone (or anything extra really). Now (since version 0.7.x of that library) isodate raises an exception for such dates, but the current implementation in zeep handles this and does, if I'm not mistaken, the same thing.
This format with date and timezone without time might be invalid according to ISO 8601, but I think it is according to XML Schema / XSD. If you look at the w3c specification for date type, there it's stated, that a date represents an interval of a day, starting form the specified date, hour 00:00:00, and if timezone offset is attached, it tells you what time zone is this zero hour in. Now, i guess ideally a datetime object would be returned, but the existing code expects date. But even so, depending on the interpretation, the date that should be returned might have different year, month, day values than the string suggests. For example, if we interpret the date we return as utc, and we receive 2024-12-31-01:00, then this is same as 2024-12-31T00:00:00-01:00, which is the same as 2025-01-01T01:00:00Z, so we should return date(2025, 1, 1).
But I might be wrong. Perhaps there isn't a proper way to handle this, other than returning a full datetime.
Maybe it would suffice to just issue a warning when the soap service returns a date with timezone, so that the user can at least notice this and then think about a preferred compromise on handling this case.