Skip to content

The type google.protobuf.timestamp.Timestamp may have a bug when used as part of generated Python protobuf library #21541

@edward-bestx

Description

@edward-bestx

What version of protobuf and what language are you using?

$ protoc --version
libprotoc 3.21.12

Language: Python

$ ~/venv/bin/python3 --version
Python 3.12.7

What operating system (Linux, Windows, ...) and version?

WSL via Windows 11. This is Ubuntu 24.10.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.10
Release:        24.10
Codename:       oracular

What runtime / compiler are you using (e.g., python version or gcc version)

$ ~/venv/bin/python3 --version
Python 3.12.7

What did you do?
Steps to reproduce the behavior:

I'm not really sure what is going on. I have tried two ways to create a protobuf object which contains a repeated google.protobuf.timestamp.Timestamp type.

Here is my .proto file.

syntax = "proto3";

import "google/protobuf/timestamp.proto"

message BidAskTimeseries {
    repeated double bid = 1;
    repeated double ask = 2;
    repeated google.protobuf.Timestamp timestamp = 3;
}

The two methods I tried are:

  1. Using constructor
  2. Using the .extend method of a "repeated scalar container"

Example 1:

import bid_ask_timeseries_pb2

bid_ask_timeseries = bid_ask_timeseries_pb2.BidAskTimeseries(
    bid=bid,
    ask=ask,
    timestamp=timestamp,
)

Example 2:

import bid_ask_timeseries_pb2

bid_ask_timeseries = bid_ask_timeseries_pb2.BidAskTimeseries()
bid_ask_timeseries.bid.extend(bid)
bid_ask_timeseries.ask.extend(ask)
bid_ask_timeseries.timestamp.extend(timestamp)

In both cases, the objects bid, ask and timestamp are numpy.array types containing floating point values (for bid and ask) or datetime.datetimes (for timestamp).

I see the following error in both cases:

TypeError: 'Timestamp' object cannot be interpreted as an integer

I don't understand this error message. It reads as if the type BidAskTimeseries is expecting integer type for the field timestamp instead of a datetime.

I'm not sure if this is a red herring however, since it doesn't seem to make any sense.

Metadata

Metadata

Assignees

Labels

inactiveDenotes the issue/PR has not seen activity in the last 90 days.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions