Dear Community, I would like to bump this thread for the discussion of adding Interval Type support.
How does everyone feel about moving forward with the support of Year-Month and Day-Time Intervals, especially for the part about having 16-byte signed values to represent nanoseconds. The change will first be made on the parquet community, and here is the PR : https://github.com/apache/parquet-format/pull/496/files Please feel free to provide any feedback or suggestions! Best Regards, Yun On Mon, Apr 21, 2025 at 10:29 AM Russell Spitzer <russell.spit...@gmail.com> wrote: > I think this is a pretty good idea for us to adopt in terms of > compatibility with other systems > and I really appreciate that Naren made sure to use a broad enough > definition to support all > available engines. I'm really interested to know how other folks feel > about this proposal and > I hope we can reach some common ground here. > > On Mon, Apr 21, 2025 at 12:24 PM Naren Krishna > <naren.kris...@snowflake.com.invalid> wrote: > >> Dear Community, >> >> I want to propose the addition of the Interval types to the Iceberg spec. >> A value of an Interval type represents a duration of time, and can be >> calculated by the difference between two dates or times. Intervals are >> supported across a variety of different engines (e.g. Parquet, Spark, >> Arrow, Oracle, Snowflake) and are widely used in time-series analysis for >> calculations and comparisons of time spans and date arithmetic. >> >> For more information, see this high-level proposal >> <https://docs.google.com/document/d/12ghQxWxyAhSQeZyy0IWiwJ02gTqFOgfYm8x851HZFLk/edit?usp=sharing> >> providing a recommendation to build Interval types in Iceberg following the >> ANSI SQL standard specification. Per ANSI SQL standard, this proposal >> recommends the creation of two types of Intervals: Year-Month and Day-Time >> Intervals. The linked document also details the implementations of Interval >> types in various engines and is intended to spur discussion in the Iceberg >> community. >> >> Thanks, >> Naren Krishna >> >
