> I assume Ryan's +1 means he is comfortable with the Java implementation
The Java implementation needs to be reviewed like other PRs. My vote here is that I think the direction and the spec changes look correct, which is the scope of this vote: "adopting the format change described in GH-583: Define ordering for INT96 timestamps" If you're unsure, just reach out and ask. I would also recommend not voting based on opinions expressed by others. If you're unsure or haven't had time to review, it's perfectly fine to let the vote pass or fail on its merits. On Thu, Jun 25, 2026 at 2:56 PM Ryan Blue <[email protected]> wrote: > > I assume Ryan's +1 means he is comfortable with the Java implementation > > The Java implementation needs to be reviewed like other PRs. My vote here > is that I think the direction and the spec changes look correct, which is > the scope of this vote: "adopting the format change described in GH-583: > Define ordering for INT96 timestamps" > > If you're unsure, please reach out and ask. > > On Thu, Jun 25, 2026 at 11:57 AM Daniel Weeks <[email protected]> wrote: > >> +1 (binding) >> >> On Thu, Jun 25, 2026 at 5:00 AM Gang Wu <[email protected]> wrote: >> >> > +1 (binding) >> > >> > I just went through the spec change and it looks good. >> > >> > On Thu, Jun 25, 2026 at 6:24 PM Andrew Lamb <[email protected]> >> > wrote: >> > > >> > > +1 >> > > >> > > ( with regards to older versions of arrow-rs panic'ing, We can also >> > release >> > > patched versions of older releases if it becomes a problem in >> practice) >> > > >> > > On Thu, Jun 25, 2026 at 4:17 AM Micah Kornfield < >> [email protected]> >> > > wrote: >> > > >> > > > +1 (binding), I assume Ryan's +1 means he is comfortable with the >> Java >> > > > implementation (which isn't approved yet but all of his comments >> were >> > > > addressed), and Rust implementation is done by Ed who is a >> maintainer >> > of >> > > > that code base. >> > > > >> > > > I'll call out the small risk that the sort order is being written >> > > > unconditionally in the implementations. This presents a risk for >> Arrow >> > rust >> > > > readers prior Arrow-rs 57, where new sort orders will cause panics, >> but >> > > > given the Rust community feels it is safe to do this, I am OK with >> it. >> > > > >> > > > Cheers, >> > > > Micah >> > > > >> > > > On Wed, Jun 24, 2026 at 3:43 PM Ryan Blue <[email protected]> wrote: >> > > > >> > > > > +1 (binding) >> > > > > >> > > > > On Wed, Jun 24, 2026 at 4:07 AM Divjot Arora via dev < >> > > > > [email protected]> >> > > > > wrote: >> > > > > >> > > > > > Hi folks, >> > > > > > >> > > > > > I'd like to propose a vote on adopting the format change >> described >> > > > > > in GH-583: Define ordering for INT96 timestamps. This was >> proposed >> > on >> > > > the >> > > > > > mailing list [1] and in Github issue #583 [2]. >> > > > > > >> > > > > > The proposed spec changes can be found in >> > > > > > https://github.com/apache/parquet-format/pull/584. We have >> > reference >> > > > > > implementations in parquet-java ( >> > > > > > https://github.com/apache/parquet-java/pull/3610) and arrow-rs >> ( >> > > > > > https://github.com/apache/arrow-rs/pull/10106) and the arrow-rs >> > > > > > implementation has been verified against a test file produced by >> > > > > > parquet-java ( >> https://github.com/apache/parquet-testing/pull/115). >> > > > > > >> > > > > > The vote will be open for at least 72 hours. >> > > > > > >> > > > > > [ ] +1 Approve the proposed format change >> > > > > > [ ] +0 No opinion >> > > > > > [ ] -1 Do not approve (please provide specific reasons) >> > > > > > >> > > > > > Thanks, >> > > > > > Divjot Arora >> > > > > > >> > > > > > [1] >> > https://lists.apache.org/thread/tjsz7fo8vlmgtdrwjthtok4v8jf2ntx0 >> > > > > > [2] https://github.com/apache/parquet-format/issues/583 >> > > > > > >> > > > > >> > > > >> > >> >
