DatetimeWithNanoseconds.timestamp_pb() returns incorrect seconds for fractional timestamps #18561

• I determined this is the correct repository in which to report this bug.

DatetimeWithNanoseconds.timestamp_pb() can return a Timestamp whose seconds field is one second too high when the value has a fractional part.

Environment

• google-api-core 2.40.0, installed from google-cloud-python main at 9b96af76254c33b9c3e0ceb390bbaeab2e33bbea
• protobuf 7.36.2
• Python 3.12.3, Ubuntu 24.04.3 LTS

This belongs to the hand-written packages/google-api-core helper, rather than a generated client. The archived python-api-core repository points here.

No supporting files or Cloud service configuration are required.

Reproduction

from google.api_core.datetime_helpers import DatetimeWithNanoseconds
from google.protobuf.timestamp_pb2 import Timestamp

for text in (
    "1969-12-31T23:59:59.123456789Z",
    "1965-01-02T03:04:05.123456789Z",
    "9999-12-31T23:59:59.999999999Z",
    "2026-10-04T12:34:56.123456789Z",
):
    actual = DatetimeWithNanoseconds.from_rfc3339(text).timestamp_pb()
    expected = Timestamp()
    expected.FromJsonString(text)
    print(text, (actual.seconds, actual.nanos), (expected.seconds, expected.nanos))

Output, with the actual pair followed by the expected pair:

1969-12-31T23:59:59.123456789Z (0, 123456789) (-1, 123456789)
1965-01-02T03:04:05.123456789Z (-157668954, 123456789) (-157668955, 123456789)
9999-12-31T23:59:59.999999999Z (253402300800, 999999999) (253402300799, 999999999)
2026-10-04T12:34:56.123456789Z (1791117296, 123456789) (1791117296, 123456789)

For the first two inputs, actual.ToJsonString() gives a time one second later. For the year-9999 input, it raises ValueError because the seconds exceed the protobuf timestamp range. The modern-date control is correct.

Expected behavior and likely cause

timestamp_pb() should match protobuf's Timestamp.FromJsonString() for the same RFC 3339 value.

The helper currently uses int(delta.total_seconds()). Before 1970, this truncates negative fractional seconds toward zero, while protobuf requires the preceding whole second plus non-negative nanoseconds. Near the upper date limit, the floating-point conversion rounds up to the next second.

Calculating seconds from delta.days * 86400 + delta.seconds should avoid both problems without changing how nanoseconds are stored. No credentials or network access are needed to reproduce this.