-
-
Notifications
You must be signed in to change notification settings - Fork 61
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
Comments
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 |
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). |
Cool so if I figure out how to the serializer config to reach the converters, we want 3 behaviors: always, never and non-zeros |
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
|
Can you put this snippet somewhere in the documentation? |
Feel free to open a pr with the docs example |
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:
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 back2023-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.
The text was updated successfully, but these errors were encountered: