Open elwinar opened 1 year ago
Thank you for the big report, submitting a PR to change the line to f"{delta.total_seconds():f}".split(".")
(an f string would be preferred here) would be a great help. A test case could go in test_features.py test_to_dict_datetime_values
Here you go https://github.com/danielgtaylor/python-betterproto/pull/448. I've had to trim 0s first before padding to keep the same alignment properties because the format seems to have a default precision of 6.
Awesome thank you
I have a field in a message that is a very small timedelta (initialized with
timedelta(microseconds=11)
). When converting this to JSON using theto_dict
method, I end-up with the value represented like1.1e-050s
.The reason is this line https://github.com/danielgtaylor/python-betterproto/blob/master/src/betterproto/__init__.py#L1535, the float is converted to a string using
str
, which defaults to scientific notation for small values. Then, the padding part is adding 0s until there is 3/6/9 chars after the ., which in this case result in the value being incorrectly shifted 48 positions to the right :joy: .Switching the line to
"{:f}".format(delta.total_seconds()).split(".")
should solve the issue by preventing scientific notation. This seems to be the original intention, and as a bonus it makes interoperability with other parsers easier. For example, I discovered with because the program consuming said message once converted in JSON is written in Go, and thetime.ParseDuration
doesn't understand scientific notation and is considering thee
as an unit (which it doesn't know about, thus fail.)Do you want me to submit a PR? I've had a look around the test suite and couldn't find the correct place to add a testcase for this, but I'll be glad to add it too if pointed in the right direction.