Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible wrong handling of timezones in dates #1444

Open
nezumisama opened this issue Nov 13, 2024 · 0 comments
Open

Possible wrong handling of timezones in dates #1444

nezumisama opened this issue Nov 13, 2024 · 0 comments

Comments

@nezumisama
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant