You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@drill.apache.org by Andries Engelbrecht <ae...@maprtech.com> on 2015/04/02 21:04:50 UTC
Re: "Illegal instant due to time zone offset transition"
Would this be the right syntax for drill-override.conf for the user timezone?
drill.exec: {
cluster-id: “xyz",
zk.connect: “abc:5181",
user.timezone: "UTC"
}
—Andries
On Mar 15, 2015, at 8:19 PM, Jacques Nadeau <ja...@apache.org> wrote:
> BOOT means it comes from drill-override.conf (or the defaults) and cannot
> be set via ALTER [SYSTEM|SESSION]. Note that -D works for all options that
> are in drill-override.conf but the better habit is to use the conf file.
>
> On Sun, Mar 15, 2015 at 6:28 PM, Andries Engelbrecht <
> aengelbrecht@maprtech.com> wrote:
>
>> Under the sys.options I noticed there is a user.timezone option.
>> Unfortunately it seems to be a BOOT option, and also I was not able to set
>> it with alter system or session.
>>
>> Ideally it will be best for this to be runtime option that can be set at
>> session level, so different users can use a different timezone. Filed for
>> an enhancement, but see if you can get the sys option to work.
>>
>> --Andries
>>
>> On Sat, Mar 14, 2015 at 12:45 PM, Vince Gonzalez <vince.gonzalez@gmail.com
>>>
>> wrote:
>>
>>> In case anyone runs into this, the turned out to be trivial. Add
>>> -Duser.timezone=UTC to DRILL_JAVA_OPTS in drill-env.sh.
>>>
>>> On Thu, Mar 12, 2015 at 4:20 PM, Vince Gonzalez <
>> vince.gonzalez@gmail.com>
>>> wrote:
>>>
>>>> I've got a query that throws the following exception:
>>>>
>>>> 0: jdbc:drill:zk=node1:5181,node2:5181,node3:> select
>>>> SpotPrice,`Timestamp` from dfs.tmp.`spot_prices` order by `Timestamp`;
>>>> +------------+------------+
>>>> | SpotPrice | Timestamp |
>>>> +------------+------------+
>>>> Query failed: Query failed: *Failure while running fragment., Cannot
>>>> parse "2015-03-08 02:58:51": Illegal instant due to time zone offset
>>>> transition (America/New_York)* [ de543f7b-2a65-472b-a62c-59441d8d9daa
>> on
>>>> node2:31010 ]
>>>>
>>>> I guess due to daylight savings, 02:58:51 doesn't exist (in
>>>> America/New_York we go from 2am to 3am when we "spring ahead").
>>>>
>>>> I see a user.timezone option of type "BOOT". Does changing this to UTC
>>>> work around this kind of DST related issue? If so, how do I set this?
>>>>
>>>> --vince
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>>
>> Andries Engelbrecht
>>
>> Solution Architect
>>
>> aengelbrecht@maprtech.com
>>
>>
>> mapr.com <http://www.mapr.com/>
>>
Re: "Illegal instant due to time zone offset transition"
Posted by John Omernik <jo...@omernik.com>.
Is there a way to have the UDF or drill itself handle this? This seems like
an odd issue to push to the user and/or the cluster administrator. (I just
posted my own issue on this in the user list, not seeing this thread)
On Thu, May 7, 2015 at 7:06 PM, Hao Zhu <hz...@maprtech.com> wrote:
> Per my test, setting drill-override.conf like below can not work.
> It will add another configuration "drill.exec.user.timezone" which does not
> take effect.
> Adding
> -Duser.timezone=UTC to DRILL_JAVA_OPTS in drill-env.sh works.
>
>
> drill.exec: {
> cluster-id: “xyz",
> zk.connect: “abc:5181",
> *user.timezone: "UTC"*
> }
>
> > select * from sys.options where name like '%timezone%';
>
> +------------+------------+------------+------------+------------+------------+------------+
> | name | kind | type | num_val | string_val |
> bool_val | float_val |
>
> +------------+------------+------------+------------+------------+------------+------------+
> | drill.exec.user.timezone | STRING | BOOT | null | "UTC"
> | null | null |
> | user.timezone | STRING | BOOT | null | "America/New_York"
> | null | null |
>
> +------------+------------+------------+------------+------------+------------+------------+
>
> Thanks,
> Hao
>
> On Thu, Apr 2, 2015 at 12:04 PM, Andries Engelbrecht <
> aengelbrecht@maprtech.com> wrote:
>
> > Would this be the right syntax for drill-override.conf for the user
> > timezone?
> >
> > drill.exec: {
> > cluster-id: “xyz",
> > zk.connect: “abc:5181",
> > user.timezone: "UTC"
> > }
> >
> > —Andries
> >
> >
> > On Mar 15, 2015, at 8:19 PM, Jacques Nadeau <ja...@apache.org> wrote:
> >
> > > BOOT means it comes from drill-override.conf (or the defaults) and
> cannot
> > > be set via ALTER [SYSTEM|SESSION]. Note that -D works for all options
> > that
> > > are in drill-override.conf but the better habit is to use the conf
> file.
> > >
> > > On Sun, Mar 15, 2015 at 6:28 PM, Andries Engelbrecht <
> > > aengelbrecht@maprtech.com> wrote:
> > >
> > >> Under the sys.options I noticed there is a user.timezone option.
> > >> Unfortunately it seems to be a BOOT option, and also I was not able to
> > set
> > >> it with alter system or session.
> > >>
> > >> Ideally it will be best for this to be runtime option that can be set
> at
> > >> session level, so different users can use a different timezone. Filed
> > for
> > >> an enhancement, but see if you can get the sys option to work.
> > >>
> > >> --Andries
> > >>
> > >> On Sat, Mar 14, 2015 at 12:45 PM, Vince Gonzalez <
> > vince.gonzalez@gmail.com
> > >>>
> > >> wrote:
> > >>
> > >>> In case anyone runs into this, the turned out to be trivial. Add
> > >>> -Duser.timezone=UTC to DRILL_JAVA_OPTS in drill-env.sh.
> > >>>
> > >>> On Thu, Mar 12, 2015 at 4:20 PM, Vince Gonzalez <
> > >> vince.gonzalez@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> I've got a query that throws the following exception:
> > >>>>
> > >>>> 0: jdbc:drill:zk=node1:5181,node2:5181,node3:> select
> > >>>> SpotPrice,`Timestamp` from dfs.tmp.`spot_prices` order by
> `Timestamp`;
> > >>>> +------------+------------+
> > >>>> | SpotPrice | Timestamp |
> > >>>> +------------+------------+
> > >>>> Query failed: Query failed: *Failure while running fragment., Cannot
> > >>>> parse "2015-03-08 02:58:51": Illegal instant due to time zone offset
> > >>>> transition (America/New_York)* [
> de543f7b-2a65-472b-a62c-59441d8d9daa
> > >> on
> > >>>> node2:31010 ]
> > >>>>
> > >>>> I guess due to daylight savings, 02:58:51 doesn't exist (in
> > >>>> America/New_York we go from 2am to 3am when we "spring ahead").
> > >>>>
> > >>>> I see a user.timezone option of type "BOOT". Does changing this to
> UTC
> > >>>> work around this kind of DST related issue? If so, how do I set
> this?
> > >>>>
> > >>>> --vince
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> Andries Engelbrecht
> > >>
> > >> Solution Architect
> > >>
> > >> aengelbrecht@maprtech.com
> > >>
> > >>
> > >> mapr.com <http://www.mapr.com/>
> > >>
> >
> >
>
Re: "Illegal instant due to time zone offset transition"
Posted by Hao Zhu <hz...@maprtech.com>.
Per my test, setting drill-override.conf like below can not work.
It will add another configuration "drill.exec.user.timezone" which does not
take effect.
Adding
-Duser.timezone=UTC to DRILL_JAVA_OPTS in drill-env.sh works.
drill.exec: {
cluster-id: “xyz",
zk.connect: “abc:5181",
*user.timezone: "UTC"*
}
> select * from sys.options where name like '%timezone%';
+------------+------------+------------+------------+------------+------------+------------+
| name | kind | type | num_val | string_val |
bool_val | float_val |
+------------+------------+------------+------------+------------+------------+------------+
| drill.exec.user.timezone | STRING | BOOT | null | "UTC"
| null | null |
| user.timezone | STRING | BOOT | null | "America/New_York"
| null | null |
+------------+------------+------------+------------+------------+------------+------------+
Thanks,
Hao
On Thu, Apr 2, 2015 at 12:04 PM, Andries Engelbrecht <
aengelbrecht@maprtech.com> wrote:
> Would this be the right syntax for drill-override.conf for the user
> timezone?
>
> drill.exec: {
> cluster-id: “xyz",
> zk.connect: “abc:5181",
> user.timezone: "UTC"
> }
>
> —Andries
>
>
> On Mar 15, 2015, at 8:19 PM, Jacques Nadeau <ja...@apache.org> wrote:
>
> > BOOT means it comes from drill-override.conf (or the defaults) and cannot
> > be set via ALTER [SYSTEM|SESSION]. Note that -D works for all options
> that
> > are in drill-override.conf but the better habit is to use the conf file.
> >
> > On Sun, Mar 15, 2015 at 6:28 PM, Andries Engelbrecht <
> > aengelbrecht@maprtech.com> wrote:
> >
> >> Under the sys.options I noticed there is a user.timezone option.
> >> Unfortunately it seems to be a BOOT option, and also I was not able to
> set
> >> it with alter system or session.
> >>
> >> Ideally it will be best for this to be runtime option that can be set at
> >> session level, so different users can use a different timezone. Filed
> for
> >> an enhancement, but see if you can get the sys option to work.
> >>
> >> --Andries
> >>
> >> On Sat, Mar 14, 2015 at 12:45 PM, Vince Gonzalez <
> vince.gonzalez@gmail.com
> >>>
> >> wrote:
> >>
> >>> In case anyone runs into this, the turned out to be trivial. Add
> >>> -Duser.timezone=UTC to DRILL_JAVA_OPTS in drill-env.sh.
> >>>
> >>> On Thu, Mar 12, 2015 at 4:20 PM, Vince Gonzalez <
> >> vince.gonzalez@gmail.com>
> >>> wrote:
> >>>
> >>>> I've got a query that throws the following exception:
> >>>>
> >>>> 0: jdbc:drill:zk=node1:5181,node2:5181,node3:> select
> >>>> SpotPrice,`Timestamp` from dfs.tmp.`spot_prices` order by `Timestamp`;
> >>>> +------------+------------+
> >>>> | SpotPrice | Timestamp |
> >>>> +------------+------------+
> >>>> Query failed: Query failed: *Failure while running fragment., Cannot
> >>>> parse "2015-03-08 02:58:51": Illegal instant due to time zone offset
> >>>> transition (America/New_York)* [ de543f7b-2a65-472b-a62c-59441d8d9daa
> >> on
> >>>> node2:31010 ]
> >>>>
> >>>> I guess due to daylight savings, 02:58:51 doesn't exist (in
> >>>> America/New_York we go from 2am to 3am when we "spring ahead").
> >>>>
> >>>> I see a user.timezone option of type "BOOT". Does changing this to UTC
> >>>> work around this kind of DST related issue? If so, how do I set this?
> >>>>
> >>>> --vince
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >>
> >> Andries Engelbrecht
> >>
> >> Solution Architect
> >>
> >> aengelbrecht@maprtech.com
> >>
> >>
> >> mapr.com <http://www.mapr.com/>
> >>
>
>