Bug #68374 Timestamp and datetime with microseconds not supported
Submitted: 14 Feb 2013 7:36 Modified: 3 Jun 2013 18:56
Reporter: Davide Prade Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Workbench: Modeling Severity:S1 (Critical)
Version:5.2.46 OS:Windows (MySQL Server 5.6.10)
Assigned to: CPU Architecture:Any
Tags: DATETIME(6), microseconds, TIMESTAMP(6)

[14 Feb 2013 7:36] Davide Prade
Description:
In EER diagram is not possible to set column Datatype to "TIMESTAMP(6)" or "DATETIME(6)".

Similarly is not possible to "reverse engineer" a table that contains a column with these datatypes.

How to repeat:
delimiter $$

CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET utf8 */$$

CREATE TABLE `t1` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `col1` varchar(45) DEFAULT NULL,
  `ts` timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8$$

Database --> Reverse Engineer
[14 Feb 2013 9:43] MySQL Verification Team
Hello Davide,

Thank you for the report.

Verified as described on reported versions(WB: 5.2.46 and MySQL Server 5.6.10).

Thanks,
Umesh
[9 May 2013 14:44] Jim Flagg
This bug is not just for Modeling.  It also affects the SQL editor.  The 6 in CURRENT_TIMESTAMP(6) has a red underline even through it is valid syntax.

It also affects ALTER TABLE.  You can't alter an existing table and change a TIMESTAMP field into a TIMESTAMP(3) field.
[9 May 2013 15:25] Jim Flagg
Just to clarify my last comment.

You can modify a field with something like this:
alter table mytable modify column log_time timestamp(3);

But you can't do it by right clicking on a table and say ALTER TABLE and change a timestamp field to timestamp(3).  The response is "No changes detected"
[3 Jun 2013 18:56] Alfredo Kojima
Duplicate of bug #68191
[22 Aug 2013 19:21] Karl Nicoletti
This is STILL happening on the shiny new MySQL Workbench 6.0.6.11184 and MySQL Server 5.6.12.

Can we PLEASE get some action on this? My work around is that I have to forward engineer the model to create the schema *.sql, then run a sed script to change the definitions from DATETIME to DATETIME(6). After that I can check in the schema *.sql file to version control. Clearly, the model and schema file are now out of sync.