What is the reason behind dateTime.XsdLiteral method logic

[fly]

Hello. I wonder what is the reason behind logic in dateTime.XsdLiteral?
I'm asking because currently this method may produce incorrect XML if PreserveInputTimeZone is True. According to python documentation, there’s no requirement for return value of tzname method.

For example, “GMT”, “UTC”, “-500”, “-5:00”, “EDT”, “US/Eastern”, “America/New York” are all valid replies

But XML has more strict specification of timezone representation.
I wanted to create PR with fix. But it appears that return value.isoformat() gives good enough result without any additional logic.

[pabigot]

Short answer: the code implements section 3.2.7.2 since XsdLiteral is intended to produce the canonical representation.

Reviewing the git logs suggests this code came from 048b9d2 in response to this ticket.

PreserveInputTimeZone was added latter to support this expectation. In the normal case the tzinfo associated with the value is always UTC. I agree a preserved arbitrary time zone opens the possibility of invalid XML as a side effect of preserving the fact that the times were not converted to UTC.

In any case, I don't believe simply using value.isoformat() will satisfy the requirements. What you'd have to do is detect that tzinfo is not UTC, and construct a 3.2.7.3-conformant representation of the corresponding offset, taking into account DST, using that instead of a tzname lookup. pyxb.utils.utility.LocalTimeZone or something like it might do it, assuming it's a Python library subclass of tzinfo that's returning non-ISO8601 timezone names in whatever context you ran into trouble.

[fly]

I see, thank you for explanation. I'm currently using workaround for this but I will try to submit PR once I have a little bit more free time.