TIME column is shown as TIMESTAMP in THL

[GoogleCodeExporter]

What steps will reproduce the problem?

1. using RBR, insert a TIME value with only microseconds in it (00:00:00.01)
2. Check replication
3. check THL

desc boundaries1;
+-------+--------------+------+-----+----------------------+--------------------
------------+
| Field | Type         | Null | Key | Default              | Extra              
            |
+-------+--------------+------+-----+----------------------+--------------------
------------+
| id    | int(11)      | NO   | PRI | NULL                 |                    
            |
| c     | char(20)     | YES  |     | NULL                 |                    
            |
| ti    | time(6)      | YES  |     | NULL                 |                    
            |
| d     | date         | YES  |     | NULL                 |                    
            |
| dt    | datetime(6)  | YES  |     | NULL                 |                    
            |
| ts    | timestamp(6) | NO   |     | CURRENT_TIMESTAMP(6) | on update 
CURRENT_TIMESTAMP(6) |
+-------+--------------+------+-----+----------------------+--------------------
------------+

# master
insert into boundaries1 values (5, 'test', '00:00:00.01',null,null,null);

# slave
select * from boundaries1 where id=5;
+----+------+-----------------+------+------+----------------------------+
| id | c    | ti              | d    | dt   | ts                         |
+----+------+-----------------+------+------+----------------------------+
|  5 | test | 00:00:00.010000 | NULL | NULL | 2013-08-26 08:01:19.560939 |
+----+------+-----------------+------+------+----------------------------+

What is the expected output?

replication happens correctly, and the TIME value is shown in THL

What do you see instead?

Replication happens correctly, but the THL shows a TIMESTAMP value instead of 
just the TIME column:

$ thl list -charset utf8 -seqno 199
SEQ# = 199 / FRAG# = 0 (last frag)
- TIME = 2013-08-26 08:01:19.0
- EPOCH# = 0
- EVENTID = mysql-bin.000002:0000000000047947;0
- SOURCEID = f1-qa-continuent-com
- METADATA = [mysql_server_id=10;dbms_type=mysql;service=cookbook;shard=test]
- TYPE = com.continuent.tungsten.replicator.event.ReplDBMSEvent
- OPTIONS = [foreign_key_checks = 1, unique_checks = 1]
- SQL(0) =
 - ACTION = INSERT
 - SCHEMA = test
 - TABLE = boundaries1
 - ROW# = 0
  - COL(1: ) = 5
  - COL(2: ) = test
  - COL(3: ) = 1970-01-01 00:00:00.01
  - COL(4: ) = NULL
  - COL(5: ) = NULL
  - COL(6: ) = 2013-08-26 08:01:19.560939

What is the possible cause?

N/A

What is the proposed solution?

adjust the THL visualisation to show only the TIME 

Additional information

Original issue reported on code.google.com by g.maxia on 26 Aug 2013 at 4:08

[GoogleCodeExporter]

Giuseppe, I can't reproduce this. Either (a) it has been fixed by time handling 
changes in 2.2.0 or (b) it's because of different MySQL versions.

Firstly, MySQL 5.5 doesn't provide parts of second:

*** START OF snippet ***

mysql [localhost] {msandbox} (demo) > insert into timetest values (1, 
'00:00:00.01', now());
Query OK, 1 row affected (0.05 sec)

mysql [localhost] {msandbox} (demo) > select * from timetest;
+----+----------+---------------------+
| id | ti       | ts                  |
+----+----------+---------------------+
|  1 | 00:00:00 | 2013-10-15 09:19:30 |
+----+----------+---------------------+
1 row in set (0.00 sec)

mysql [localhost] {msandbox} (demo) > insert into timetest values (2, 
'00:00:01', now());
Query OK, 1 row affected (0.01 sec)

mysql [localhost] {msandbox} (demo) > select * from timetest;
+----+----------+---------------------+
| id | ti       | ts                  |
+----+----------+---------------------+
|  1 | 00:00:00 | 2013-10-15 09:19:30 |
|  2 | 00:00:01 | 2013-10-15 09:20:27 |
+----+----------+---------------------+
2 rows in set (0.00 sec)

*** END OF snippet ***

Secondly, THL displays TIME type correctly:

*** START OF snippet ***

SEQ# = 2 / FRAG# = 0 (last frag)
- TIME = 2013-10-15 11:19:30.0
...
- SQL(0) =
 - ACTION = INSERT
 - SCHEMA = demo
 - TABLE = timetest
 - ROW# = 0
  - COL(1: id) = 1
  - COL(2: ti) = 00:00:00
  - COL(3: ts) = 2013-10-15 11:19:30.0
SEQ# = 3 / FRAG# = 0 (last frag)
- TIME = 2013-10-15 11:20:27.0
...
- SQL(0) =
 - ACTION = INSERT
 - SCHEMA = demo
 - TABLE = timetest
 - ROW# = 0
  - COL(1: id) = 2
  - COL(2: ti) = 00:00:01
  - COL(3: ts) = 2013-10-15 11:20:27.0

*** END OF snippet ***

Original comment by linas.vi...@continuent.com on 15 Oct 2013 at 9:26

• Changed state: QA

[GoogleCodeExporter]

The bug occurs with MySQL 5.6

set binlog_format=row;
create table t1 (i int not null, t time(6));
insert into t1 values (2, '00:00:00.02');

SEQ# = 3 / FRAG# = 0 (last frag)
- TIME = 2013-12-06 12:09:37.0
- EPOCH# = 0
- EVENTID = mysql-bin.000002:0000000000000983;0
- SOURCEID = 127.0.0.1
- METADATA = [mysql_server_id=101;dbms_type=mysql;service=tsandbox;shard=test]
- TYPE = com.continuent.tungsten.replicator.event.ReplDBMSEvent
- OPTIONS = [foreign_key_checks = 1, unique_checks = 1]
- SQL(0) =
 - ACTION = INSERT
 - SCHEMA = test
 - TABLE = t1
 - ROW# = 0
  - COL(1: ) = 2
  - COL(2: ) = 1970-01-01 00:00:00.02

Original comment by g.maxia on 6 Dec 2013 at 11:11

• Changed state: Started

[GoogleCodeExporter]

Original comment by g.maxia on 6 Dec 2013 at 11:11

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by g.maxia on 6 Dec 2013 at 11:12

• Added labels: FixedIn-2.2.1
• Removed labels: FixedIn-2.2.0

[GoogleCodeExporter]

Original comment by linas.vi...@continuent.com on 2 May 2014 at 9:14

• Added labels: FixedIn-3.0.0
• Removed labels: FixedIn-2.2.1

[GoogleCodeExporter]

These are not at the focus of 3.0.0.

Original comment by linas.vi...@continuent.com on 26 May 2014 at 2:21

• Added labels: FixedIn-3.0.1
• Removed labels: FixedIn-3.0.0

[GoogleCodeExporter]

Will not use third version digit for normal releases anymore. It will only be 
increment for maintenance ones.

Original comment by linas.vi...@continuent.com on 26 May 2014 at 5:01

• Added labels: FixedIn-3.1.0
• Removed labels: FixedIn-3.0.1

[GoogleCodeExporter]

This issue affects the MongoDB applier. If we replicate a timestamp "10:10:30" 
it will be applied as "1970-01-01 10:10:30."

Original comment by g.maxia on 30 Jun 2014 at 4:02

• Added labels: Heterogeneous, MongoDB, Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

Original comment by linas.vi...@continuent.com on 19 Jan 2015 at 2:18

• Added labels: FixedIn-4.0.1
• Removed labels: FixedIn-3.1.0