[Bug]: Timestamp(float seconds) truncates instead of rounding, losing a microsecond #40235

What happened?

Timestamp(seconds) truncates instead of rounding when seconds is a float, so it can land one microsecond below the value the caller passed.

The constructor does:

total = int(seconds * _POW_10[precision]) + int(subseconds)

seconds * 1e6 is a float multiplication, so for many values it lands just under the exact integer (2.000002 * 1e6 == 2000001.9999999998), and int() truncates toward zero rather than rounding to nearest:

>>> from apache_beam.utils.timestamp import Timestamp
>>> Timestamp(2.000002).micros
2000001          # expected 2000002
>>> Timestamp(1.000001).micros
1000000          # expected 1000001

This hits the most common way of building a timestamp, Timestamp.of(time.time()):

>>> t = time.time()      # 1790158166.5462177
>>> Timestamp.of(t).micros
1790158166546217         # the float is ...546218 to the microsecond

Taking microsecond values, converting them to float seconds the way a caller would, and feeding them back in, 1.2% come back one microsecond low (2436 of 200000 random epoch-range values).

The class docstring says "If seconds is a float, the fractional part will be captured up to precision digits", and explains that integer storage is used precisely because "floating point values lose precision" — but the conversion into that integer storage is itself lossy. Truncation is also asymmetric about zero, which sits oddly with "an int of floored seconds".

Issue Priority

Priority: 3 (minor)

Issue Components

• Component: Python SDK
• Component: Java SDK
• Component: Go SDK
• Component: Typescript SDK
• Component: IO connector
• Component: Beam YAML
• Component: Beam examples
• Component: Beam playground
• Component: Beam katas
• Component: Website
• Component: Infrastructure
• Component: Spark Runner
• Component: Flink Runner
• Component: Samza Runner
• Component: Twister2 Runner
• Component: Hazelcast Jet Runner
• Component: Google Cloud Dataflow Runner