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

Full precision of XmlDateTime is not preserved #917

Closed
chrismostert opened this issue Jan 15, 2024 · 6 comments
Closed

Full precision of XmlDateTime is not preserved #917

chrismostert opened this issue Jan 15, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@chrismostert
Copy link
Contributor

chrismostert commented Jan 15, 2024

We are currently running into an issue where we expect XmlDateTime values to be te same after a roundtrip (parsing the .xml file and then writing it back again). We would expect the following input to serialize back to the same input string:

from xsdata.models.datatype import XmlDateTime

input = "2023-11-23T19:38:38.000"
output = str(XmlDateTime.from_string(input))

Here the string representation (and the value in any eventual serialized .xml file) becomes 2023-11-23T19:38:38 while we would expect the XmlDateTime object to preserve the full precision of the time component, giving back 2023-11-23T19:38:38.000.

It seems that the fractional seconds are purposefully truncated, is there any reason that xsdata does this? We'd rather see that the full precision of the time is preserved, and commenting out the linked line of code results in the desired behaviour.

Could this be changed so that the franctional seconds are no longer truncated if they are zero? If this results in undesired behaviour elsewhere, then I could also see this being a toggle in for example the configuration for the XmlSerializer.

@tefra
Copy link
Owner

tefra commented Jan 15, 2024

xsdata was inspired from java's jaxb, I think that was default behaviour.

I ''l take a look on how easy it's to expose it as a serializer configuration option

@tefra tefra added the enhancement New feature or request label Jan 15, 2024
@skinkie
Copy link
Contributor

skinkie commented Jan 17, 2024

It seems that the fractional seconds are purposefully truncated, is there any reason that xsdata does this? We'd rather see that the full precision of the time is preserved, and commenting out the linked line of code results in the desired behaviour.

I have had my users complain about the exact oposite. The fractions actually being there while not intended. So maybe an explicit remove fractional would also be nice (now doing a replace on every instance).

@tefra
Copy link
Owner

tefra commented Jan 18, 2024

Cool so if I figure out how to the serializer config to reach the converters, we want 3 behaviors: always, never and non-zeros

@tefra
Copy link
Owner

tefra commented Mar 9, 2024

Most datetime parser support either approach, it's usually people who do some sort of manual parsing that need something like this, I guess.

In any way most libraries follow this pattern, if you want you can override the XmlDateTime converter to apply this logic

from xsdata.formats.converter import Converter, converter

class MyXmlDateTimeConverter(Converter):

    def deserialize(self, value: Any, **kwargs: Any) -> Any:
        return XmlDateTime.from_string(value)

    def serialize(self, value: Any, **kwargs: Any) -> str:
        if isinstance(value, XmlDateTime):
            return "whatever you want"


converter.register_converter(XmlDateTime, MyXmlDateTimeConverter())

@tefra tefra closed this as completed Mar 9, 2024
@skinkie
Copy link
Contributor

skinkie commented Mar 9, 2024

Can you put this snippet somewhere in the documentation?

@tefra
Copy link
Owner

tefra commented Mar 9, 2024

Can you put this snippet somewhere in the documentation?

Feel free to open a pr with the docs example

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

No branches or pull requests

3 participants