>Csaba, is that possible with th change similar to how it is now, or would
>it have to be rewritten?

Keeping the old implementation and switching with flag:
It is Attila's change, so he knows best the cost of keeping the old
solution. I think that is not impossible to do this, but some parts would
have to be rewritten.
I am especially worried about testing: there are already 2 flags that
affect timestamp handling in the backend (use_local_tz_for_unix_
timestamp_conversions, convert_legacy_hive_parquet_utc_timestamps), and a
flag that switches between the timezone implementations would interact with
both of them, so a lot of tests would have to be duplicated to give a good
coverage.

The new timezone db makes it possible to add timezone aliases in a text
file, so it may be possible to add all the current timezone names by
default. This still wouldn't be a perfect solution, because lot of the
current aliases are ambiguous or wrong, so I would prefer to remove them by
default.
On Mon, Jun 11, 2018 at 11:49 PM, Jim Apple <[EMAIL PROTECTED]> wrote:

> Phil, if Jeszy's solution is possible (feature flag, off by default in the
> 3.x line), would that align with your preference?
>
> On Mon, Jun 11, 2018 at 2:29 PM, Taras Bobrovytsky <[EMAIL PROTECTED]>
> wrote:
>
> > I agree with Jim. It would be better to bump to 4.0 in my opinion. We
> > should follow the simple rule: Breaking changes must bump the major
> version
> > number.
> >
> > On Mon, Jun 11, 2018 at 2:17 PM, Jeszy <[EMAIL PROTECTED]> wrote:
> >
> > > My assumption was that the workaround Phil mentioned must be simple to
> > > toggle (e.g. flag). If it's not, it probably shouldn't be considered a
> > > viable workaround.
> > >
> > > On 11 June 2018 at 10:42, Jim Apple <[EMAIL PROTECTED]> wrote:
> > >
> > > > Csaba, is that possible with th change similar to how it is now, or
> > would
> > > > it have to be rewritten?
> > > >
> > > > On Mon, Jun 11, 2018 at 1:30 AM Jeszy <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > I think we should include it in 3.1, with the feature disabled by
> > > default
> > > > > (to not break on a minor upgrade), but recommend enabling it in
> docs
> > > and
> > > > > make it enabled by default in 4.0.
> > > > >
> > > > > On 11 June 2018 at 10:23, Jim Apple <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > > Any more thoughts? This question is for everyone in the Impala
> > > > community.
> > > > > >
> > > > > > Right now the plan is to fold it into 3.1, with two to one in
> favor
> > > of
> > > > > that
> > > > > > over bumping to 4.0.
> > > > > >
> > > > > > On Mon, Jun 4, 2018 at 8:48 PM Jim Apple <[EMAIL PROTECTED]>
> > > wrote:
> > > > > >
> > > > > > > I am more in favor of bumping to 4.0. It is a rapid escalation,
> > but
> > > > we
> > > > > > > wouldn’t be the first open source project to switch to a model
> > with
> > > > > Short
> > > > > > > major versions, as both Clang and Firefox have done so.
> > > > > > >
> > > > > > > I also feel that, both from a semver perspective and as a user
> of
> > > > other
> > > > > > > software, I expect breaking changes to bump the major version
> > > number.
> > > > > > >
> > > > > > > That said, this is not a hill I’m trying to die on. My focus is
> > on
> > > > the
> > > > > > > user experience, and if our users end up well informed of the
> > > > > breakages,
> > > > > > > then I will feel we have done our job, no matter what version
> > > number
> > > > we
> > > > > > > stamp on it.
> > > > > > >
> > > > > > > On Mon, Jun 4, 2018 at 7:57 PM Philip Zeyliger <
> > > [EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Hi Csaba!
> > > > > > >>
> > > > > > >> I would be fine with both proposals, with a slight preference
> to
> > > B.
> > > > My
> > > > > > >> understanding is that you're going to expose a way to define
> > > > overrides
> > > > > > for
> > > > > > >> time zone definitions, so there will be pretty workable
> > > workarounds
> > > > > too.
> > > > > > >>
> > > > > > >> -- Philip
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB