Bug #8523 Microseconds precision is not retained by TIME, DATETIME, and TIMESTAMP fields
Submitted: 15 Feb 2005 20:47 Modified: 6 Dec 2011 17:25
Reporter: Christopher Miller Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Data Types Severity:S4 (Feature request)
Version:5.1 OS:Linux (Red Hat 9)
Assigned to: CPU Architecture:Any
Tags: bfsm_2006_12_07
Triage: Triaged: D5 (Feature request)

[15 Feb 2005 20:47] Christopher Miller
Description:
Microseconds precision is not retained by TIME, DATETIME, and TIMESTAMP field types. 

mysql> CREATE TEMPORARY TABLE TEST ( T1 TIME, T2 TIMESTAMP );
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO TEST ( T1, T2 ) VALUES ( '12:13:14.000015', '2005-02-16 12:13:14.000015' );
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM TEST;
+----------+---------------------+
| T1       | T2                  |
+----------+---------------------+
| 12:13:14 | 2005-02-16 12:13:14 |
+----------+---------------------+
1 row in set (0.00 sec)

mysql> SELECT MICROSECOND(T1), MICROSECOND(T2) FROM TEST;
+-----------------+-----------------+
| MICROSECOND(T1) | MICROSECOND(T2) |
+-----------------+-----------------+
|               0 |               0 |
+-----------------+-----------------+
1 row in set (0.00 sec)

How to repeat:
See above script. 

Suggested fix:
No specific fix recommendation.
[3 May 2005 17:46] Boris Burtin
I'd also like to see this fixed.  The date functions support microseconds, bow useful are they if there's no way to *store* a date value with microseconds.
[22 Jun 2005 19:40] Stephen
I am using 4.1.10 and I also would like to see this work:

mysql> select now(), DATE_FORMAT( now(), '%H:%i:%S.%f' );
+---------------------+-------------------------------------+
| now()               | DATE_FORMAT( now(), '%H:%i:%S.%f' ) |
+---------------------+-------------------------------------+
| 2005-06-22 15:38:59 | 15:38:59.000000                     |
+---------------------+-------------------------------------+
1 row in set (0.00 sec)
[30 Jun 2005 8:52] Yoshiaki Tajika
I think so, too. 
As Mysql usage grows, milli-sec and micro-sec become more needed.
For example, 
- recording passage of vast amounts of RFID.
- forensic. I mean andit log of database access for security.
and so on. 
Would you please tell us what this request's priority is for you(mysql), and when we can get it.
[6 Mar 2006 21:14] Tim Sheehy
I'd like to see this fixed as I'm trying to set up an auditing database by just dumping the old records into a history table before updating.  The easiest way to do this is to key the history table the same as the regular table but add a key based on time. However, with precision only to the second, only 1 change per second is allowed using this strategy.
[6 Mar 2006 21:14] Tim Sheehy
I'd like to see this fixed as I'm trying to set up an auditing database by just dumping the old records into a history table before updating.  The easiest way to do this is to key the history table the same as the regular table but add a key based on time. However, with precision only to the second, only 1 change per second is allowed using this strategy.
[14 Mar 2006 20:50] Oriol Garrote
Hi,
I'm trying to make a sport results applicattion with mysql in my website. All my website is in MySQL, but now I've found the limitation of the TIME data type: it can't retain fractions of seconds. It's a really strange thing that MS SQL server or  a non commercial database like PostgreSQL have fractions of seconds precision and MySQL doesn't. Now I'm considering switching to PostgreSQL.
I hope that developers try to solve it in some way.
Thanks
[28 Apr 2006 8:52] [ name withheld ]
TIME, TIMESTAMP, and DATETIME do not support parts of seconds (for example          from DATE_FORMAT()). The simplest way to solve this task is to make a small UDF.

#include <my_global.h>
#include <my_sys.h>
#include <mysql.h>

#include <stdio.h>
#include <sys/time.h>
#include <time.h>
#include <unistd.h>

/* Copyright (c) 2006 Wadimoff <wadimoff@yahoo.com>                            */
/* Created:  27 April 2006                                                            */

/* NOW_MSEC() returns a character string representing the current date and time       */
/* with milliseconds in format YYYY-MM-DD HH:MM:SS.mmm  e.g.: 2006-04-27 17:10:52.129 */

/* How to install:                                                                    */
/* #1  gcc -shared -o now_msec.so now_msec.cc -I /usr/local/include/mysql             */
/* #2  cp now_msec.so /usr/lib                                                        */
/*     Comment : you can copy this wherever you want in the LD path                   */
/* #3  Run this query :                                                               */
/*     CREATE FUNCTION now_msec RETURNS STRING SONAME "now_msec.so";                  */
/* #4  Run this query to test it:                                                     */
/*     SELECT NOW_MSEC();                                                             */
/*     It should return something like that                                           */
/*                                                                                    */
/* mysql> select NOW_MSEC();                                                          */
/* +-------------------------+                                                        */
/* | NOW_MSEC()              |                                                        */
/* +-------------------------+                                                        */
/* | 2006-04-28 09:46:13.906 |                                                        */
/* +-------------------------+                                                        */
/* 1 row in set (0.01 sec)                                                            */

extern "C" {
   my_bool now_msec_init(UDF_INIT *initid, UDF_ARGS *args, char *message);
   char *now_msec(
               UDF_INIT *initid,
               UDF_ARGS *args,
               char *result,
               unsigned long *length, char *is_null, char *error);
}

my_bool now_msec_init(UDF_INIT *initid, UDF_ARGS *args, char *message) {
   return 0;
}

char *now_msec(UDF_INIT *initid, UDF_ARGS *args, char *result,
               unsigned long *length, char *is_null, char *error) {

  struct timeval tv;
  struct tm* ptm;
  char time_string[20]; /* e.g. "2006-04-27 17:10:52" */
  long milliseconds;
  char *msec_time_string = result;
  time_t t;

  /* Obtain the time of day, and convert it to a tm struct. */
  gettimeofday (&tv, NULL);

  t = (time_t)tv.tv_sec;
  ptm = localtime (&t);   /* ptm = localtime (&tv.tv_sec); */

  /* Format the date and time, down to a single second.  */
  strftime (time_string, sizeof (time_string), "%Y-%m-%d %H:%M:%S", ptm);

  /* Compute milliseconds from microseconds. */
  milliseconds = tv.tv_usec / 1000;

  /* Print the formatted time, in seconds, followed by a decimal point
     and the milliseconds.  */
  sprintf(msec_time_string, "%s.%03ld\n", time_string, milliseconds);

  /* Hint: http://www.mysql.ru/docs/man/UDF_return_values.html */

  *length = 23;

  return(msec_time_string);
}

That's all.
[21 Jul 2006 22:10] Jeremy Chambers
I ran into this today too; when I round-trip a timestamp from java to mysql, it comes back with the miliseconds chopped off ... now I know why.
[17 Aug 2006 20:15] Sami Shalabi
A limitation that I would love to see addressed...
[1 Apr 2007 3:22] Ben Valentine
Here is another vote for a fix
[2 Apr 2007 21:25] Eric George
Yet another vote to fix this please!!!
Integer seconds just isn't good enough for many applications, particularly in the sciences.  Many of my tables now include a datetime column and a float fractional_second column - but it's an ugly & expensive kludge.

Another suggestion would be conversions to & from astronomical julian dates - but that's pretty niche.

Thanks
[16 Apr 2007 4:34] Valeriy Kravchuk
Bug #27838 was marked as a duplicate of this one.
[27 Apr 2007 4:10] Riz Joj
Thought of using log4j JDBC with MySQL. However the fact that milliseconds are not stored makes it difficult to perform useful reports on the log entries to a MySQL database as so many entries come in within a second.
[23 May 2007 18:47] Andrew McLaughlin
Is this bug dead? Does it take more than two years to fix this? When is the planned rollout of this?

Andrew
[25 May 2007 16:24] Stephen Pietrowicz
I would like to have this bug fix too.  The log files I want to store have time stamps that contain microseconds, and this information is silently deleted on insertion!
[31 May 2007 8:51] harjeev chug
if you couldn'yt fix this bug in 2 yrs then i think i should switch back to MSSql
[21 Jun 2007 23:17] Peter McCulloch
Speaking as someone who's storing musical information in a database, it would be REALLY nice to have timing at the microsecond level available.
[20 Jul 2007 14:42] Daren Schwenke
Another vote for this bug to be fixed.  
I'm currently using timestamp to determine which fields need to be updated for php/ajax applications, and the dropping of the microseconds creates a possible race condition during the client update.
[3 Aug 2007 2:45] Jean-Guy Mossu
Right now, I'm switching back to MS SQL because I really need microseconds in the timestamp.

But hopefully this will be fixed in a future version and if possible, I would like to give MySql another try.
[3 Aug 2007 17:03] Chris Calender
Microsecond precision has been pushed into 5.1 tree.

It should be available in 5.1.21.
[3 Aug 2007 17:12] Jean-Guy Mossu
Thanks for your answer.  It is indeed good news for me.
[3 Aug 2007 17:13] Chris Calender
The patch that has been committed is for microseconds in the slow query log. (Not for all TIMESTAMP, TIME, and DATETIME types).

I've confirmed that this will be included in 5.1.22.
[3 Aug 2007 17:22] Jean-Guy Mossu
Hi, I'm not sure I understand.

Is it the "patch that has been committed is for microseconds in the slow query
log" that will be available in 1.5.22 or the possibilité to store microseconds in the TIMESTAMP, TIME, and DATETIME data types?

Thanks again for your feedback.
[3 Aug 2007 17:29] Chris Calender
Hi Jean-Guy,

I'm sorry for the confusion.  The patch that has been submitted is only to include microseconds in the slow query log.

It will not include microseconds for TIMESTAMP, TIME, and DATETIME types yet.
[3 Aug 2007 17:43] Jean-Guy Mossu
Hi Chris,

Thanks again for the quick answer.

Is it possible for you to give us an approximate idea of the timeline for fixing the Timestamp problem?

I can live for some time without microseconds in the Timestamp, but I know that eventually I will need those microseconds.

I can imagine that this problem isn't an easy thing to solve, so maybe you don't know when or have no immediate plans concerning this issue.
[7 Sep 2007 13:58] Sveta Smirnova
Bug #30893 was marked as duplicate of this one.
[19 Sep 2007 14:13] Daren Schwenke
Bump. Still using seconds since the epoch plus microseconds in an integer field as a workaround.
[13 Nov 2007 20:15] Pavel Alexeev
Thanks for the UDF NOW_MSEC() to unknown author.

And when would be realized the full support of milliseconds?
[13 Nov 2007 21:52] Pavel Alexeev
and, forgot, I'm pack it UDF into RPM for Fedora (~8). Rpms (both, binaries and src.rpm) placed in my yum repository: http://hubbitus.org.ru/rpm/MySQL-UDF-now_msec/
[20 Feb 2008 8:32] bodri bodri
I'm logging processes start and end time.
I need the millis because when I sort them I got them in the wrong order if their times
differ only in the millis field.
Please provide this feature in the future.
[20 Feb 2008 9:09] Pavel Alexeev
bodri bodri, UDF NOW_MSEC() as present before working perfectly for this purpose. If you are logging more faster, and need even more precision for example microseconds instead milliseconds?? I'm made UDF NOW_MICTOSECOND by example NOW_MSEC of Wadimoff <wadimoff@yahoo.com>

It is placed here (binaries and sources) http://hubbitus.net.ru/rpm/Fedora7/MySQL-UDF-now_microsec/
I hope was helpful.
[20 Feb 2008 9:09] Pavel Alexeev
bodri bodri, UDF NOW_MSEC() as present before working perfectly for this purpose. If you are logging more faster, and need even more precision for example microseconds instead milliseconds?? I'm made UDF NOW_MICTOSECOND by example NOW_MSEC of Wadimoff <wadimoff@yahoo.com>

It is placed here (binaries and sources) http://hubbitus.net.ru/rpm/Fedora7/MySQL-UDF-now_microsec/ , http://hubbitus.net.ru/rpm/Fedora8/MySQL-UDF-now_microsec/
I hope was helpful.
[11 Mar 2008 19:12] Nathan Atkinson
I really would love to see this bug fixed as well, I am a relativley basic user, and uploading a UDF is way out of my league.
[11 Mar 2008 19:31] Pavel Alexeev
Nathan Atkinson, I'm not a developer of mysql, but installing UDF is much easier than it might seems. Only 4 steeps, as wrote Wadimoff in comment befor, or much easier if you using Fedora - just install my binary packages - this is 1 command (but, you will need root privileges in any case)!
[24 Mar 2008 7:35] Sourav Sipani
Another vote for this bug to fixed. Microseconds would be ideal but milliseconds are a must.
[24 Mar 2008 7:35] Sourav Sipani
Another vote for this bug to be fixed. Microseconds would be ideal but milliseconds are a must.
[2 Jul 2008 3:03] Michael Haselton
Another vote to see this is fixed.
[22 Aug 2008 8:32] Aniruddha Shival
Milliseconds are really useful. Please fix this bug as early as possible.
[28 Aug 2008 15:37] Jorge Urdaneta
Yet another vote! please fix this bug
[28 Aug 2008 20:49] Pavel Alexeev
Why UDF is not suitable? Performance issue or why???
[29 Aug 2008 20:19] Ben Wern
Do the UDF solutions referenced above simply allow NOW to be invoked with milli or micro second precision, or do they allow storage at that level of detail?
[30 Aug 2008 4:06] Pavel Alexeev
>Do the UDF solutions referenced above simply allow NOW to be invoked with milli
>or micro second precision
No. But it is not needed, IMHO. So, if required this precision you may use additional functions with (or instead of) NOW. By default they precision is overhead and also will work slowly.

>or do they allow storage at that level of detail?
I don't understand this question. Why you can't store any value from any function anywhere?
If you talk about store datetime value in one field with that precision, yes, it is not allowed now in default types, but may be easy emulated (f.e. in text representation)
[5 Sep 2008 2:34] Ben Wern
Pavel,

I'm not sure I understand what you are saying in terms of it not being needed - it's certainly needed for a LOT of applications that I can think of. In my particular case, PLCs that need to log a LOT of data with very precise time/dates.

Wouldn't storing this level time data in a text field be very expensive to sort/index/search on as opposed to a dedicated time field (datetime or similar)? I guess my concern with inserting datetime into a text field is that the selects to recall the data are going to kill my performance.
[5 Sep 2008 8:41] Pavel Alexeev
Ben Wern,

I'm say what not needing change NOW to get this precision, not provide this possibility at all.
NOW used ubiquitously, and many places microseconds not needed. So, adding it only cause old applications to work slowly.

About performance of string representation - I do not make any tests or benchmarks. But, I guess what it is not be very slow. In any case, if this overhead do not acceptable, you may use any other representation such us addition integer field for microseconds and use them in operations together with datetime.
[30 Oct 2008 15:46] jim kraai
My workaround, instead of text date, is to use an int(14) and populating it with a custom integer timestamp: ( unix timestamp with microseconds ) * 10000

Indexing and arithmetic are efficient.  As long as we remember the factor of 10000 when coding, it works just fine.

This is a compromise with trade offs.  I can't seem to get anything in the Windows build of 5.0.51b (upgrading is not an option) to yield fractional seconds from the system clock, so the custom timestamp has to be generated outside of the database.  In this case, the application server generating the timestamp is on a different machine.

So, since I can't use the db server's clock as authoritative, conflicts will eventually arise when the application servers' and the db server's clocks diverge.
[19 Dec 2008 13:31] Felix Dierich
To add another view:

We are using MySQL and other DBs (e.g. Oracle) with Hibernate with the same application. It was quite a surprise to learn that MySQL does not support milliseconds - this is pretty much a knock-out criterion for MySQL with some of our applications, e.g. for log keeping applications or configuration change tracking application. 

We have applied workarounds like extra floating point columns for some software, but this is not possible in a clean way when you use Hibernate to abstract from the DB. Also patching the MySQL code would destroy some of our customer's acceptance for MySQL - most insist on Oracle anyway and it is hard to persuade them to go for something else. 

Although MySQL is otherwise a great product, things like this will not make it easier for commercial acceptance of MySQL, especially in large industrial applications. I can understand that changing the datatype implementation in a software like MySQL has massive implications, but I'm sure it would be worth it for the future of the product.
[13 Jan 2009 6:16] Tim Koopmans
I've posted a hacky solution for storing milliseconds with datetime values here.
http://90kts.com/blog/2009/storing-milliseconds-in-mysql/

Hope that helps.
[9 Feb 2009 6:58] Gabriele Tozzi
Another vote to see this is fixed.
[17 Feb 2009 22:20] Paul Craven
Do the developers have any timescales for fixing this?
It really is a huge hole in MySQL....
[21 Feb 2009 11:55] Thomas Ene
I would like to see this fixed as well in an official release.

Thomas
[27 Feb 2009 11:13] Pascal Calovini
Another vote to see this is fixed.
[27 Feb 2009 11:14] Pascal Calovini
Another vote to see this is fixed.

even in Excel I can fix it with formatting to hh:mm:ss,000

seems to be very hard to be fixed after 3 years.
[9 Mar 2009 8:03] Asuka Kenji Siu Ching Pong
Another vote here.

If the microsecond value could not be stored easily because of compatibility reasons, etc., it should at least be retrieve-able, so that the users have a choice of storing it.
[9 Mar 2009 8:04] Asuka Kenji Siu Ching Pong
Another vote here.

If the microsecond value could not be stored easily because of compatibility reasons, etc., it should at least be retrieve-able by a built-in function, so that the users have a choice of storing it.
[12 Mar 2009 18:41] Yu Chen
We need this one fixed ASAP! We can't differentiate transactions happens within a second.
[12 Mar 2009 18:53] ed bras
Just a little tip:
If you use Hibernate or som other ORM/Data mapping, just define your own Data Type and you are done... very simple. 
You just store the date in milliseconds in the database and let the Date Type convert it back and forward to a Date object.

Just my thoughts...
Ed
[25 Mar 2009 16:00] Larsen Doe
Hi Ed,
do you have any links that further explain your proposal?

+1 for fixing this bug

Lars
[25 Mar 2009 16:12] ed bras
Here it is.
Have a look at this:
http://hibernate.org/272.html
Here a user type is created to store/load java Enum data types directly in/from the database.

You can do exactly the same as with the java Data type.

In short:
Write your own Date user type, something like MyDate user type. 
This class extends from implements EnhancedUserType and MyDate will be asked by Hibernate to fill the Date object. You then simple load the millesoncds from the database from some numberic database field and create a new Date object with it. And visa versa... 
Takes you really nothing to implement this and works very well.

Usage: in you hibernate mapping file you define the user type with the typedef tag and give it a name. This name is then used as type attribute in the property tag... 
That's it... isn't that nice ;)

Good luck,
Ed
[2 Apr 2009 0:35] Noel Akins
I'm not the best coder in the world. I have to work the asp.net and mysql. And, I generally love mysql. But, I ran into a issue trying to use DateTime as the base for page updates. I was really shocked to find out the mysql wouldn't store fractional seconds. I find it hard to believe that this issue hasn't be resolved in 5.0. I hope this gets some attention soon.
[2 Apr 2009 11:09] Larsen Doe
Hi Ed,

thanks! It was quite hard to implement as I am new to Hibernate and additionally had to switch from xdoclet to annotations.

The complete solution can be found at the Hibernate forums: http://forum.hibernate.org/viewtopic.php?p=2409970#2409970

hth,
Lars
[2 Apr 2009 11:15] ed bras
He Lars,

Great to hear that it worked. Always nice to hear to some feedback.

-- Ed
[19 Apr 2009 15:30] Ryan Ryan
My bully postgres friends made fun of me saying MySQL isn't a real database.  They said, "It doesn't even store miliseconds!".  "Try out DBase or something from the late seventies if I wanted a better database."

I thought surely they were missing something.  There's probably an alternate type that they don't know about.

Sure enough, I find myself logging a queue of events, having to read them back months and decipher which one came first.  I guess I need need to use PostgreSQL?

Seriously, what are you putting into MySQL 6 that's more important than this?  

Sincerely,

Die-hard MySQL fan
[22 Apr 2009 7:00] Jeff Peff
Please for pete's sake... FIX this :(
[22 Apr 2009 8:53] ed bras
Now that Oracle toke over Sun, it will proabably never be fixed ;)....

I switched to Postgresql. Performs much better without bugs in case you need correct transactions.

-- Ed
[4 May 2009 7:30] alastair knowles
Not sure if there is any point adding to this, given the number of comments. Anyway, I am using MySQL to build a peer to peer application, and I want to use date/time as my primary key, as it gives me a simple, growable key space. I need milli/microsecond precision. Really surprised this is not supported.
[28 May 2009 9:42] Yuri Kirilin
Yet another vote to have this feature realized
[31 May 2009 2:37] Peter Thairu
Please fix this soon!!
[4 Jun 2009 11:37] Konstantin Osipov
Bug#31013 is related to this bug.
[10 Aug 2009 8:34] Darren Cassar
I too need this feature and blogged about it here: http://mysqlpreacher.com/wordpress/2009/08/once-upon-a-timestampmilliseconds/

Guys please also read:
http://blogs.mysql.com/peterg/2009/08/07/fractional-seconds-precision-in-mysql-datetime-da...
and vote on: http://forge.mysql.com/worklog/task.php?id=946

This will help shift this feature higher up in the "important features to be developed" list.

Cheers,
Darren
[8 Feb 2010 17:27] Mike Nicewarner
Come on, guys!  Storing TIMESTAMP isn't that hard!  Please consider doing it like IBM did in DB2, using half-bytes for the components.  That gives you a TIMESTAMP that uses 10 bytes of storage:
Year: 2
Month: 1
Day: 1
Hour: 1
Minute: 1
Second: 1
Sub-second: 3

PLEASE, PLEASE fix this bug!
[9 Mar 2010 21:00] Vishu Bokkisam
It (having a native support for fractional secs) would make it easier for others who care for the milli/micro/nano secs precision to easily switch from other DBs like PostgreSQL etc..

Go Oracle Go!!, grab some more customers with the addition of this...
[9 Mar 2010 21:19] Ben Wern
Uhh.. nevermind? This sat so long that I've actually designed MySQL out of the solution to get around it (several long term bugs - or "feature requests" depending on your perspective.)
[21 Apr 2010 13:21] Koma Komauskis
This ticket is open for 5 years and yet still it's not enough for beloved MySQL team to find a moment to implement feature that has been so wanted.

From this point it seems that it will take another five years to implement and properly test it.
[21 Apr 2010 16:03] Change Data
I’ve found a possible work around to this. Page 230, in a book called “High Performance MySQL”, lists a User-Defined Function (UDF) called “NOW_USEC” this UDF creates a string in the same format as MySQL date, but also includes millisecond precision. The UDF is also listed here (along with installation details):

http://www.xaprb.com/blog/2007/10/30/how-i-built-the-now_usec-udf-for-mysql/

I have compiled and linked this UDF to my server and works perfectly. To store the value returned by NOW_USEC() just create a field with data type: varchar(26). I know you’ll have to re-link this UDF every time you upgrade your MySQL server, but it’s the best solution I’ve seen so far.

Read more: http://mysqlpreacher.com/wordpress/2009/08/once-upon-a-timestampmilliseconds/#ixzz0lkd70Jb...
[21 Apr 2010 20:59] Pavel Alexeev
Change Data, is it better then UDFs posted in this bug before? How?
[21 Apr 2010 21:03] Pavel Alexeev
Change Data, is it better then UDFs posted in this bug before? How?
[21 Apr 2010 21:12] Pavel Alexeev
Change Data, is it better then UDFs posted in this bug before? How?
[22 Apr 2010 9:31] Pavel Alexeev
Change Data, is it better then UDFs posted in this bug before? How?
[21 May 2010 18:06] Farid Zidan
I would like to have an optional parameter for timestamp (and other datetime, time datatypes) that specifies the precision of the fraction part. By default the fraction part is 0 so existing code does not have to change, but apps that needs second fractions can specify how many from 0 up to 3 or 7 depending on server capability. Example,

col1 timestamp -- no fraction
col1 timestamp(3) -- milliseconds precision
[6 Jul 2010 19:34] Robert La Ferla
Can MySQL give you the current timestamp accurate to the nearest microsecond?
[21 Jul 2010 9:13] Leo Bosnjak
We are using mysql to log some debug strings into a database, as there may be many entries in one second, we'd need a way to store the datetime in milliseconds ;-)
So millisecond support would be really great..
[27 Jul 2010 14:18] James Young
Related WL https://intranet.mysql.com/worklog/Server-BackLog/?tid=946 updated so request is included in work planned for MySQL 5.6.  GeirH added to notification and will verify feasibility.
[28 Sep 2010 22:22] Scott Jilek
So what is the status of this since July? Will fractional timestamps FINALLY be supported in version 5.6?   I have numerous apps that I could convert to use mysql if this were supported, but have been waiting years for you to come in line with all other databases (besides MS Access)

I have many colleagues who have the same complaint as I have - fractional timestamps are not simply a feature request, but an absolute requirement.
[20 Oct 2010 20:27] marek chovanec
Can you please let us know if this is in progress or it's wontfix?

As a way around I am using long instead of datetime everywhere but it would be great CURRENT_TIMESTAMP could return miliseconds.
[20 Oct 2010 21:14] Boris Burtin
We can pretty much draw our own conclusions, based on the date that the bug was submitted.  Damn, we missed the 5-year anniversary.  Maybe we should all get together to celebrate the 10-year.  What are you doing on Feb. 15, 2015?
[21 Oct 2010 7:59] Cyrille Giquello
And perhaps we could by some Oracle instances to store milliseconds ?
[15 Dec 2010 20:51] Timothy Burrington
I would also like to express my interest in seeing this corrected before I "shuffle off this mortal coil".

It makes it really hard to use MySQL for some financial applications since you can't store microsecond precision in the database and then later do comparison on it using date/time functions.  This is especially important when in regards to compliance obligations.
[23 Dec 2010 2:16] Benjamin Renaud
Let me add my voice to the chorus. It's completely silly that you guys don't support this.
[24 Jan 2011 14:07] Colin MacKenzie
This is pretty retarded that I cant get at least a millisecond timestamp. We are coming up on the 6th anniversary of this bug. I call it a bug, not a feature request, because someone apparently implemented the date/time functions to support milliseconds but didnt finish it. wonderful.

Like a previous bug reporter said, "What are you putting into 6 that is more important than this?"
[29 Jan 2011 13:31] Oscar Despradel
Can you please let us know if you are working on this??
[1 Feb 2011 17:48] Juan Diego Quesada Ocampo
Hoping this issue will be addressed sometime soon. In my case I need to store with great precision when certain trades have took place to know which of those have their risk covered by comparing times.
[28 Feb 2011 20:30] Joshua Davis
I vote for this feature too.   At least millisecond accuracy would be great.
[28 Feb 2011 21:08] ed bras
I have been following this bug now for about 4 years and communicated about it with the Oracle/Sun teams before.
My Conclusion: it will take at least another 2-4 years before this bug/feature is implemented.
Neither do I understand this but that's how it it...
My action: moved to postgresql... Much better in many interesting aspects that are important for me.
[20 Mar 2011 18:18] Tyler Style
Also want to see this... micro/milliseconds can be important when you're logging events from a web application.
[13 Apr 2011 11:01] Ian Rogers
How can this be hard to solve? An 8-byte unsigned field storing the time in microseconds since 1970 solves this AND the end-of-epoch 2037 problem!

2 ^ 62 / ( 1000000 * 60 * 60 * 24 * 365) =~ 584,000 years 

Heck, make it signed and you can store dates a quarter of a billion years in the past too...
[11 May 2011 18:00] Mike Kruckenberg
Guessing there's little hope MySQL will ever get more granular datetime. microseconds is critical to our app so like other commenters I switched to postgresql, did a ton of digging into the workarounds and just not worth staying with MySQL on this project.
[11 May 2011 19:18] Scott Jilek
Can anyone from the dev team comment if this will EVER happen?  Is there something preventing this feature from being implemented, or is it just not a "priority"?

Heck, even SQLite can work with nanoseconds even though it has no native Date/Time data types!!!!

Query:
select strftime('%Y-%m-%d %H:%M:%f', '2011-01-01 00:00:00.050','+0.5 seconds')

Result:
2011-01-01 00:00:00.550
[19 May 2011 22:55] Matthias Meyer
I wonder why this is considered a feature request.
In my opinion this a bug. 
People expect a timestamp to be the count of milliseconds since 1970-01-01 00:00:00.00
and not the count of seconds.

But whatever: +1 for fixing this asap.
[21 May 2011 18:36] Austin Kalb
I am storing stock market data - its a pretty wide rangeing field. Millisec support is crutial these days. I can believe I just upgraded to this latest version and its still not there!

So any suggestions on another database to use (win 2003 server)?

Thx
Austin
[4 Jul 2011 10:34] ed bras
Just use Postgres. 
These day's runs very smooth on almost every platform which is nice for testing and feels like a real db.

I switched to Postgres because of this bug and happy ever since (I develop on Windows and test/production/acceptance environment all run on linux.

- Ed
[8 Jul 2011 11:07] Bastian Knerr
Hi MySQL,
I just could not believe my integration tests to fail on this one. All time info below second's resolution swallowed silently is an epic fail for a data type called 'timestamp'. Quite a while ago since milliseconds have been invented...
No nanos is one thing but not to provide millis for the data types 'timestamp','time',etc is just a shame.

Best regards
Bastian
[29 Aug 2011 13:29] Benjamin Haller
Can´t believe it´s still not available. :-O
[30 Sep 2011 13:07] magali decocker
Also waiting for this "Fix"...
[21 Oct 2011 10:13] balta balta
High priority on this please!
[31 Oct 2011 23:41] Dimitriy A
Forced to use awkward workarounds for storing milliseconds. Please get this feature into MySQL.
[1 Nov 2011 13:28] Scott Jilek
Is there *anything* we can do to get this massive deficiency fixed?  Is it a money issue?  I'd be more than willing to give a monetary donation/bounty specifically to get this fixed.
[1 Nov 2011 15:13] Sergei Golubchik
MariaDB supports microseconds for a few months already.
http://kb.askmonty.org/en/microseconds-in-mariadb
[10 Nov 2011 8:44] Florian Gruber
Please!
[20 Nov 2011 6:53] Charles Swenson
Could not figure out why this did not work... then I found this is a longstanding issue. Just wish there was some type of explanation
[6 Dec 2011 17:25] Paul Dubois
Noted in 5.6.4 changelog.

MySQL now supports fractional seconds for TIME, DATETIME, and
TIMESTAMP values, with up to microsecond precision.
[6 Dec 2011 18:17] Dimitriy A
That is a great accomplishment for MySQL Team! Thank you. This has been a long waited feature.