[ 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