[MCOL-714] Inconsistency in from_unixtime() Created: 2017-05-11  Updated: 2022-11-05  Resolved: 2022-11-05

Status: Closed
Project: MariaDB ColumnStore
Component/s: MariaDB Server
Affects Version/s: 1.0.8
Fix Version/s: Icebox

Type: Bug Priority: Major
Reporter: nathan aschoff Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: nash
Environment:

Debian 8.7 (Jessie)


Epic Link: Time, Timestamp and Timezone

 Description   

Passing a field vs passing literal values (field value same as literal) to from_unixtime() function, produce different results, depending on the time_zone variables.


Table structure

MariaDB [testdb]> show create table testtbl\G
*************************** 1. row ***************************
       Table: testtbl
Create Table: CREATE TABLE `testtbl` (
  `unix_ts_col` bigint(20) DEFAULT NULL
) ENGINE=Columnstore DEFAULT CHARSET=latin1

Table data

MariaDB [testdb]> select * from testtbl;
+-------------+
| unix_ts_col |
+-------------+
|  1493304629 |
+-------------+

Env 01, system: CEST, global: SYSTEM, session: SYSTEM

MariaDB [testdb]> show global variables like '%time_zone';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CEST   |
| time_zone        | SYSTEM |
+------------------+--------+
 
MariaDB [testdb]> show variables like '%time_zone';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CEST   |
| time_zone        | SYSTEM |
+------------------+--------+
 
MariaDB [testdb]> select from_unixtime(unix_ts_col), from_unixtime(1493304629) from testtbl;
+----------------------------+---------------------------+
| from_unixtime(unix_ts_col) | from_unixtime(1493304629) |
+----------------------------+---------------------------+
| 2017-04-27 16:50:29        | 2017-04-27 16:50:29       |
+----------------------------+---------------------------+

Env 02, system: CEST, global: SYSTEM, session: america/new_york

MariaDB [testdb]> show global variables like '%time_zone';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CEST   |
| time_zone        | SYSTEM |
+------------------+--------+
 
MariaDB [testdb]> show variables like '%time_zone';
+------------------+------------------+
| Variable_name    | Value            |
+------------------+------------------+
| system_time_zone | CEST             |
| time_zone        | america/new_york |
+------------------+------------------+
 
MariaDB [testdb]> select from_unixtime(unix_ts_col), from_unixtime(1493304629) from testtbl;
+----------------------------+---------------------------+
| from_unixtime(unix_ts_col) | from_unixtime(1493304629) |
+----------------------------+---------------------------+
| 2017-04-27 16:50:29        | 2017-04-27 10:50:29       |
+----------------------------+---------------------------+

Env 03, system: CEST, global: america/new_york, session: america/new_york

MariaDB [testdb]> show global variables like '%time_zone';
+------------------+------------------+
| Variable_name    | Value            |
+------------------+------------------+
| system_time_zone | CEST             |
| time_zone        | america/new_york |
+------------------+------------------+
 
MariaDB [testdb]> show variables like '%time_zone';
+------------------+------------------+
| Variable_name    | Value            |
+------------------+------------------+
| system_time_zone | CEST             |
| time_zone        | america/new_york |
+------------------+------------------+
 
MariaDB [testdb]> select from_unixtime(unix_ts_col), from_unixtime(1493304629) from testtbl;
+----------------------------+---------------------------+
| from_unixtime(unix_ts_col) | from_unixtime(1493304629) |
+----------------------------+---------------------------+
| 2017-04-27 16:50:29        | 2017-04-27 10:50:29       |
+----------------------------+---------------------------+


This behavior is not witnessed in mysql 5.5/mariadb 10.0/10.1.

Expected behavior is the possibility to set the session time_zone variable and filter on fields containing epoch times, using a variable time_zone.



 Comments   
Comment by Andrew Hutchings (Inactive) [ 2017-05-11 ]

You are correct, ColumnStore is not currently aware of the session variables related to time for the MariaDB Server that is querying ColumnStore, it instead uses the system time. This is a large task to implement (due to the possibility of multiple UMs with different TZ session variables) and we should at least document it for now.

Comment by nathan aschoff [ 2017-05-11 ]

Can you advise a work-around on environment level, without changing the system tz or using arithmetic on the cell values (e.g. adding/subtracting off-sets)?

Comment by Andrew Hutchings (Inactive) [ 2017-05-11 ]

I'm not aware of one beyond what you have already mentioned. This is a problem that affects our regression suite as well which means the time based function tests fail on my UK servers. We have not come up with a solution yet because add/subtract can cause unintended side effects with things like DST. Unfortunately this is an inherited problem from InfiniDB. To solve it we need a way to push the session variable down into the PMs.

I will be working on time functionality improvements after 1.1 is released and implementing this is definitely something I could consider as part of this process.

Comment by nathan aschoff [ 2017-05-11 ]

OK. Cheers Andrew and thanks for the timely responses, as always.
I'll await this patiently.

Comment by nathan aschoff [ 2017-05-11 ]

P.S. Isn't there a way to force the function execution to the UM?

Comment by Andrew Hutchings (Inactive) [ 2017-05-11 ]

Yes, you could disable infinidb_vtable_mode which would run everything through MariaDB instead of ExeMgr/PrimProc. The downside of this is that there would be a large performance penalty:

https://mariadb.com/kb/en/mariadb/columnstore-system-variables/#operating-mode

Comment by Todd Stoffel (Inactive) [ 2022-11-05 ]

This item is being closed because it was well passed the expiration date with no activity. If you suspect this was done in error please create a new ticket.

Generated at Thu Feb 08 02:23:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.