anishmehta24 opened a new pull request, #40236: URL: https://github.com/apache/beam/pull/40236
`Timestamp(seconds)` truncated instead of rounding when `seconds` was a float, so it could land one microsecond below the value it was given: ```python >>> Timestamp(2.000002).micros 2000001 # expected 2000002 ``` `seconds * _POW_10[precision]` is a float multiplication that often lands just under the exact integer (`2.000002 * 1e6 == 2000001.9999999998`), and `int()` truncates toward zero rather than rounding to nearest. Taking microsecond values, converting them to float seconds the way a caller would, and reading them back, 1.2% came back one microsecond low (2436 of 200000 random epoch-range values). It shows up on the most common construction path too — `Timestamp.of(time.time())`. `round()` also fixes the asymmetry about zero, which sat oddly with the docstring's "int of floored seconds". The same rounding is applied to `subseconds`, which had the same `int()` call; the existing tests that pass integer or exact-binary subseconds (`micros=56`, `micros=500000`, `precision=3`/`9` cases) are unaffected. Test: `test_float_seconds_round_to_nearest_unit` covers the reported values, a negative, a non-default precision, and a microsecond round-trip through float seconds. It fails on master on the first assertion. `apache_beam/utils/timestamp_test.py` 42 passed; `timestamp_test.py + windowed_value_test.py + transforms/window_test.py` 74 passed. yapf clean. Fixes #40235 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
