Re: Date and time for next parquet sync

+1 for Tuesday On Mon, Jan 29, 2018 at 4:03 AM, Uwe L. Korn wrote: > +1, Tuesday to Thursday are ok for me but I would prefer Tuesday this week. > > Uwe > > On Mon, Jan 29, 2018, at 12:54 PM, Zoltan Ivanfi wrote: >> +1 for Tuesday, this week I can't attend on Wednesday. >> >>

Re: Next parquet sync

My preference for next week would be Tuesday as well. On Thu, Jan 4, 2018 at 8:25 AM, Zoltan Ivanfi wrote: > Hi, > > According to the latest results of the availability poll, Tuesdays seems > to work for slightly more people than Wednesdays. I'll try to post the > chart

Re: Parquet Sync

Works for me as well. On Mon, Apr 3, 2017 at 11:41 AM, Wes McKinney wrote: > +1 > > On Mon, Apr 3, 2017 at 2:31 PM, Ryan Blue wrote: >> Works for me. >> >> On Mon, Apr 3, 2017 at 11:28 AM, Julien Le Dem wrote: >> >>> I'll be in

Re: Parquet sync starting now on hangout

One thing I forgot to bring up: do we care about TIMESTAMP_MILLIS in addition to TIMESTAMP_MICROS? From SQL perspective, only the latter is needed. On Wed, Mar 8, 2017 at 1:54 PM, Julien Le Dem wrote: > 2. The other thing to look into is HyperLogLog for approximate distinct >

Re: Day of Sync-up

We didn't see any objections in the past 24 hours. Julien, could you reschedule for Wednesday? On Mon, Feb 27, 2017 at 10:30 AM, Marcel Kornacker <marc...@gmail.com> wrote: > It sounds like that only leaves Wednesday. Any objections to that? > > On Mon, Feb 27, 2017 at 12:43 AM, Z

Re: Timestamp type [was: parquet sync starting now]

h >>> explicitly noting, that "timestamp with time zone" requires functionality >>> beyond the Parquet file format to do the TZ adjustments whether that be done >>> server-side on the result sets knowing client-side TZ settings, or in the >>> client-side driver code. Obvi

Re: parquet sync starting now

gt; - > 2009-05-12 12:00:00 > 2009-05-13 12:00:00 > 2009-05-14 12:00:00 > > > BTW, Presto has come to realize their implementation is different than the > ANSI SQL standard as well. This GitHub issue [4] has a good writeup of > things. > > Referenc

Re: parquet sync starting now

not change because it is effectively maintained in UTC. > > Zoltan > > On Mon, Feb 27, 2017 at 7:34 PM Marcel Kornacker <marc...@gmail.com> wrote: >> >> On Mon, Feb 27, 2017 at 8:47 AM, Zoltan Ivanfi <z...@cloudera.com> wrote: >> > Hi, >> >

Re: parquet sync starting now

rew.cmu.edu/~shadow/sql/sql1992.txt > [2] http://www.wiscorp.com/sql_2003_standard.zip > > Zoltan > > > > On Thu, Feb 23, 2017 at 10:46 PM Marcel Kornacker <marc...@gmail.com> wrote: >> >> Regarding timestamp with timezone: I'm not sure whether the SQL >&

Re: Day of Sync-up

It sounds like that only leaves Wednesday. Any objections to that? On Mon, Feb 27, 2017 at 12:43 AM, Zoltan Ivanfi wrote: > I'm busy on Mondays and Tuesdays, the rest of the week is fine by me. > > Zoltan > > On Mon, Feb 27, 2017 at 8:28 AM Uwe L. Korn

Re: Day of Sync-up

Tuesday then? On Sat, Feb 25, 2017 at 3:49 PM, Deepak Majeti wrote: > Other days of the week work for me too. > > On Sat, Feb 25, 2017 at 3:31 PM, Wes McKinney wrote: >> >> Moving this to the Parquet mailing list. Other days of the week work >> OK

Re: parquet sync starting now

e to assemble generic vectorized processing code, > then link libarrow.a into parquet-cpp, Impala, and Kudu. I can help > with as much of the legwork as possible with this, and I think all of > our projects would benefit from the unification of efforts and unit > testing / benchmarking. > > Th

Re: parquet sync starting now

Regarding timestamp with timezone: I'm not sure whether the SQL standard requires the timezone to be stored along with the timestamp for 'timestamp with timezone' (at least Oracle and Postgres diverge on that topic). Cc'ing Greg Rahn to shed some more light on that. Regarding 'make Impala depend