+1 ________________________________ From: Chao Sun <[email protected]> Sent: Monday, May 18, 2026 2:04 PM To: [email protected] <[email protected]> Subject: Re: [VOTE] SPIP: Timestamps with nanosecond precision
+1 (binding) On Mon, May 18, 2026 at 2:01 PM Szehon Ho <[email protected]<mailto:[email protected]>> wrote: +1 (non binding) Thanks Szehon On Mon, May 18, 2026 at 8:16 AM Dongjoon Hyun <[email protected]<mailto:[email protected]>> wrote: +1 Dongjoon On 2026/05/18 12:49:04 Peter Toth wrote: > +1 (non-binding) > > On Mon, May 18, 2026 at 2:38 PM Mridul Muralidharan > <[email protected]<mailto:[email protected]>> > wrote: > > > > > +1 > > > > Mridul > > > > On Mon, May 18, 2026 at 4:52 AM Wenchen Fan > > <[email protected]<mailto:[email protected]>> wrote: > > > >> +1 (binding) > >> > >> On Mon, May 18, 2026 at 5:07 PM Menelaos Karavelas < > >> [email protected]<mailto:[email protected]>> wrote: > >> > >>> +1 (non-binding) > >>> > >>> On May 18, 2026, at 9:00 AM, serge rielau.com<http://rielau.com> > >>> <[email protected]<mailto:[email protected]>> wrote: > >>> > >>> +1 > >>> > >>> On May 15, 2026, at 6:07 PM, Stefan Kandic via dev > >>> <[email protected]<mailto:[email protected]>> > >>> wrote: > >>> > >>> +1 > >>> > >>> *From: *Max Gekk <[email protected]<mailto:[email protected]>> > >>> *Date: *Friday, 15 May 2026 at 09:53 > >>> *To: *dev <[email protected]<mailto:[email protected]>> > >>> *Subject: *Re: [VOTE] SPIP: Timestamps with nanosecond precision > >>> > >>> +1 > >>> > >>> On Fri, May 15, 2026 at 9:15 AM Max Gekk > >>> <[email protected]<mailto:[email protected]>> wrote: > >>> > >>> Hi Spark devs, > >>> > >>> I would like to call a vote on adopting the following SPIP as an > >>> official Spark SPIP, following the discussion on the list. > >>> Motivation > >>> Spark SQL today exposes TIMESTAMP / TIMESTAMP_NTZ / TIMESTAMP_LTZ at > >>> microsecond precision. Nanosecond timestamps are increasingly common in > >>> ORC > >>> and in ecosystems such as Oracle, MS SQL Server, Trino, Snowflake, and > >>> DuckDB. Spark often rejects Parquet TIMESTAMP(NANOS, …) or, with legacy > >>> flags, reads it as LongType, which drops timestamp semantics and time-zone > >>> behavior. Users are forced to pre-normalize to micros or maintain custom > >>> conversion logic. > >>> > >>> This SPIP aims to add first-class nanosecond-capable timestamps in SQL > >>> and APIs, with a clear fractional precision parameter, while keeping a > >>> practical migration path for existing microsecond workloads. > >>> Proposal (summary) > >>> > >>> - SQL surface: TIMESTAMP_NTZ(n), TIMESTAMP_LTZ(n), and TIMESTAMP(n) > >>> (including WITHOUT TIME ZONE / WITH LOCAL TIME ZONE spellings), with > >>> optional n in [0, 9]. The scope for the initial milestone focuses on 7 > >>> <= n > >>> <= 9; unparameterized types keep today’s defaults. > >>> - New Catalyst types: additive parameterized types (e.g. > >>> TimestampNTZNanosType(n) / companion for LTZ) rather than silently > >>> widening > >>> existing singleton types. > >>> - Logical value model: epochMicros (long) + nanosOfMicro in [0, 999] > >>> (short) with a single normalization rule, so Spark continues to build > >>> on > >>> the existing microsecond datetime “currency” while adding a bounded > >>> sub-micro correction. > >>> - Scope boundaries: explicit non-goals (e.g. not redefining NTZ/LTZ > >>> session semantics, not promising every connector end-to-end in v1), > >>> risks/mitigations, rough ~25 person-week estimate and success “exams” > >>> are > >>> documented in the SPIP and JIRA. > >>> > >>> Full detail, API tables, rejected alternatives, and test/migration > >>> criteria are in the SPIP document and JIRA description. > >>> > >>> Relevant links > >>> > >>> - SPIP (Google Doc): > >>> > >>> https://docs.google.com/document/d/1DeW15QueI4PdRyPm6C6jsTZFmIjbXX2j4h-Ja5W_fsg/edit?usp=sharing > >>> - Discussion thread: > >>> https://lists.apache.org/thread/xvv4qt9dpnb1kszxdqlxyv9b46749ypo > >>> - JIRA: https://issues.apache.org/jira/browse/SPARK-56822 > >>> > >>> Vote > >>> Please vote on accepting this proposal as an official SPIP (the SPIP > >>> text above; implementation and follow-up JIRAs can land incrementally > >>> after > >>> acceptance). > >>> [ ] +1: Accept the proposal as an official SPIP > >>> [ ] +0: No opinion > >>> [ ] -1: I do not think we should adopt this SPIP (please explain why) > >>> The vote will remain open for at least 72 hours. > >>> > >>> Thanks to everyone who commented on the discussion thread and helped > >>> refine the design. > >>> > >>> Best regards, > >>> Max Gekk > >>> > >>> > >>> > >>> > --------------------------------------------------------------------- To unsubscribe e-mail: [email protected]<mailto:[email protected]>
