adamreeve commented on code in PR #43537:
URL: https://github.com/apache/arrow/pull/43537#discussion_r1751117367
##########
python/pyarrow/_flight.pyx:
##########
@@ -736,16 +742,47 @@ cdef class FlightEndpoint(_Weakrefable):
CLocation.Parse(tobytes(location)).Value(&c_location))
self.endpoint.locations.push_back(c_location)
+ if expiration_time is not None:
+ self.endpoint.expiration_time = TimePoint_from_ns(
+ expiration_time.cast(timestamp("ns")).value)
Review Comment:
I tested this out and it doesn't actually fix the problem, as it isn't the
handling of the `optional` that's the problem but the `duration` type parameter
of the `time_point`.
I was getting confused trying to understand this error until I realised the
type annotation for `CFlightEndpoint.expiration_time` is wrong, it is an
`optional[CTimePoint]` in `libarrow_flight.pxd`, but in
`cpp/src/arrow/flight/types.h`, it's actually a
`std::optional<std::chrono::system_clock::time_point>` (see
[types.h](https://github.com/apache/arrow/blob/f3dd298bd32f6dc38654680c49b3f1fbf97e3d5f/cpp/src/arrow/flight/types.h#L83)).
`CTimePoint` is `std::chrono::time_point<std::chrono::system_clock,
std::chrono::nanoseconds>` (from
[python/datetime.h](https://github.com/apache/arrow/blob/f3dd298bd32f6dc38654680c49b3f1fbf97e3d5f/python/pyarrow/src/arrow/python/datetime.h#L88))
and always has nanosecond precision, but
`std::chrono::system_clock::time_point` has microsecond precision on MacOS.
--
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]
