You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 inzeep
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 adatetime
object would be returned, but the existing code expectsdate
. 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 receive2024-12-31-01:00
, then this is same as2024-12-31T00:00:00-01:00
, which is the same as2025-01-01T01:00:00Z
, so we should returndate(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.
The text was updated successfully, but these errors were encountered: