Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GH-44679: [C++][Python] Fix Flight Timestamp precision, revert workaround from #43537 #44681

Merged
merged 2 commits into from
Nov 14, 2024

Conversation

EnricoMi
Copy link
Contributor

@EnricoMi EnricoMi commented Nov 8, 2024

What changes are included in this PR?

Make arrow.flight.Timestamp nanoseconds precision and OS-independent.

Use the CTimePoint for FlightEndpoint.expiration_time to have OS-independent nanoseconds precision.

cdef cppclass CFlightEndpoint" arrow::flight::FlightEndpoint":
CFlightEndpoint()
CTicket ticket
vector[CLocation] locations
optional[time_point] expiration_time
c_string app_metadata

This reverts workaround for expiration_time from #43537.

Are these changes tested?

Existing unit tests are adjusted to the new precision.

Are there any user-facing changes?

This PR includes breaking changes to public APIs.

The values of FlightEndpoint.expiration_time now have nanoseconds precision on any operating system.

@EnricoMi EnricoMi changed the title GH-44679: [[Python] Fix Flight Timestamp precision, revert workaround from #43537 GH-44679: [Python] Fix Flight Timestamp precision, revert workaround from #43537 Nov 8, 2024
@github-actions github-actions bot added the awaiting review Awaiting review label Nov 8, 2024
@EnricoMi EnricoMi changed the title GH-44679: [Python] Fix Flight Timestamp precision, revert workaround from #43537 GH-44679: [C++][Python] Fix Flight Timestamp precision, revert workaround from #43537 Nov 8, 2024
@EnricoMi
Copy link
Contributor Author

EnricoMi commented Nov 8, 2024

Splitting this PR into the C++ part (the first commit) and the Python part (the second commit) requires the Python workaround that is being removed in the second commit to be adjusted in the first commit: #44680 (comment)

To avoid throw-away work, I'd prefer doing this in one PR.

@lidavidm lidavidm added the Breaking Change Includes a breaking change to the API label Nov 14, 2024
@github-actions github-actions bot added awaiting merge Awaiting merge and removed awaiting review Awaiting review labels Nov 14, 2024
@lidavidm lidavidm merged commit d534e77 into apache:main Nov 14, 2024
41 checks passed
@lidavidm lidavidm removed the awaiting merge Awaiting merge label Nov 14, 2024
Copy link

After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit d534e77.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants