[
https://issues.apache.org/jira/browse/IMPALA-7385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570982#comment-16570982
]
ASF subversion and git services commented on IMPALA-7385:
---------------------------------------------------------
Commit cf5de09761c21aee4f3d571a94fbee5bda306a97 in impala's branch
refs/heads/master from [~philip]
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=cf5de09 ]
IMPALA-7385: Fix test-with-docker errors having to do with time zones.
ExprTest.TimestampFunctions,
query_test.test_scanners.TestOrc.test_type_conversions, and
query_test.test_queries.TestHdfsQueries.test_hdfs_scan_node were all
failing when using test-with-docker with mismatched dates.
As it turns out, there is code that calls readlink(/etc/localtime)
and parses the output to identify the current timezone name.
This is described in localtime(5) on Ubuntu16:
It should be an absolute or relative symbolic link pointing to
/usr/share/zoneinfo/, followed by a timezone identifier such as
"Europe/Berlin" or "Etc/UTC". ... Because the timezone identifier is
extracted from the symlink target name of /etc/localtime, this file
may not be a normal file or hardlink."
To honor this requirement, and to make the tests pass, I re-jiggered
how I pass the time zone information from the host into the container.
The previously failing tests now pass.
Change-Id: Ia9facfd9741806e7dbb868d8d06d9296bf86e52f
Reviewed-on: http://gerrit.cloudera.org:8080/11106
Reviewed-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com>
Tested-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com>
> several timezone conversion tests are failing within test-with-docker context
> -----------------------------------------------------------------------------
>
> Key: IMPALA-7385
> URL: https://issues.apache.org/jira/browse/IMPALA-7385
> Project: IMPALA
> Issue Type: Task
> Reporter: Philip Zeyliger
> Priority: Major
>
> The following tests tend to fail when using test-with-docker. What's common
> about them is that they're doing a time zone conversion.
> {code}
>
> metadata.test_show_create_table.TestShowCreateTable.test_show_create_table[table_format:
> text/none] 1 min 23 sec 19
> query_test.test_queries.TestHdfsQueries.test_hdfs_scan_node[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': False, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: orc/def/block] 4.1
> sec 58
> query_test.test_scanners.TestOrc.test_type_conversions[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': False, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: orc/def/block] 16 sec
> 58
> ExprTest.TimestampFunctions
> {code}
> It turns out that people parse {{readlink(/etc/localtime)}} to find out the
> current time zone. This got noticeable when the ORC change landed (though
> I've seen that one come and go) and then very frequently when we changed time
> zone DBs. (Or so I think.)
> I have a simple change forthcoming.
--
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
