Joe McDonnell created IMPALA-8043:
-------------------------------------
Summary: ExprTest fails on Ubuntu 16 when the timezone is
America/Los_Angeles
Key: IMPALA-8043
URL: https://issues.apache.org/jira/browse/IMPALA-8043
Project: IMPALA
Issue Type: Bug
Components: Backend
Affects Versions: Impala 3.2.0
Reporter: Joe McDonnell
When setting up an Ubuntu development environment, I installed Ubuntu 16.04
using America/Los_Angeles as the timezone. When running on this configuration,
ExprTest.TimestampFunctions() fails with several timezone issues:
{noformat}
[ RUN ] ExprTest.TimestampFunctions
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:559: Failure
Value of: ConvertValue<int64_t>(result)
Actual: -28800
Expected: expected_result
Which is: 0
unix_timestamp(cast('1969-12-31 16:00:00' as timestamp))
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:559: Failure
Value of: ConvertValue<int64_t>(result)
Actual: -28800
Expected: expected_result
Which is: 0
unix_timestamp('1969-12-31 16:00:00')
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:559: Failure
Value of: ConvertValue<int64_t>(result)
Actual: -28800
Expected: expected_result
Which is: 0
unix_timestamp('1969-12-31 16:00:00', 'yyyy-MM-dd HH:mm:ss')
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:559: Failure
Value of: ConvertValue<int64_t>(result)
Actual: 0
Expected: expected_result
Which is: 28800
unix_timestamp('1970-01-01', 'yyyy-MM-dd')
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:559: Failure
Value of: ConvertValue<int64_t>(result)
Actual: 0
Expected: expected_result
Which is: 28800
unix_timestamp('1970-01-01 10:10:10', 'yyyy-MM-dd')
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:559: Failure
Value of: ConvertValue<int64_t>(result)
Actual: -28800
Expected: expected_result
Which is: 0
unix_timestamp('1969-12-31 16:00:00 extra text', 'yyyy-MM-dd HH:mm:ss')
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:289: Failure
Value of: GetValue(expr, TYPE_STRING)
Actual: "1970-01-01 00:00:00"
Expected: expected_result
Which is: "1969-12-31 16:00:00"
cast(cast(0 as timestamp) as string)
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:289: Failure
Value of: GetValue(expr, TYPE_STRING)
Actual: "1970-01-01 00:00:00"
Expected: expected_result
Which is: "1969-12-31 16:00:00"
cast(cast(0 as timestamp) as string)
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:289: Failure
Value of: GetValue(expr, TYPE_STRING)
Actual: "1970-01-01 00:00:00"
Expected: expected_result
Which is: "1969-12-31 16:00:00"
from_unixtime(0)
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:289: Failure
Value of: GetValue(expr, TYPE_STRING)
Actual: "1970-01-01 00:00:00"
Expected: expected_result
Which is: "1969-12-31 16:00:00"
from_unixtime(cast(0 as bigint))
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:289: Failure
Value of: GetValue(expr, TYPE_STRING)
Actual: "1970-01-01 00:00:00"
Expected: expected_result
Which is: "1969-12-31 16:00:00"
from_unixtime(0, 'yyyy-MM-dd HH:mm:ss')
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:289: Failure
Value of: GetValue(expr, TYPE_STRING)
Actual: "1970-01-01 00:00:00"
Expected: expected_result
Which is: "1969-12-31 16:00:00"
from_unixtime(cast(0 as bigint), 'yyyy-MM-dd HH:mm:ss')
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:289: Failure
Value of: GetValue(expr, TYPE_STRING)
Actual: "1970-01-01 08:00:00"
Expected: expected_result
Which is: "1970-01-01 00:00:00"
cast(to_timestamp(28800) as string)
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:445: Failure
Expected: (value) <= (end), actual: 1546465102 vs 1546436302
Google Test trace:
/home/joe/view2/Impala/be/src/exprs/expr-test.cc:6572:
[ FAILED ] ExprTest.TimestampFunctions (3577 ms)
{noformat}
There are a couple workarounds to this:
{noformat}
# Set UTC as timezone
sudo timedatectl set-timezone UTC
# Use actual timezone name (e.g. PST8PDT rather than America/Los_Angeles
# or CST6CDT rather than America/Chicago)
sudo timedatectl set-timezone PST8PDT{noformat}
This looks like it is coming from the tests using
TestTimestampUnixEpochConversions(). The tests work on other timezones
(Americas/La_Paz, Europe/Paris, Asia/Tokyo all work). It is likely that this is
a duplicate of some other known issue.
Filing this Jira so that others who run into this might find this workaround.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
