Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DATETIME type conversion problem #536

Closed
chaoran opened this issue Jul 11, 2013 · 9 comments · Fixed by #538
Closed

DATETIME type conversion problem #536

chaoran opened this issue Jul 11, 2013 · 9 comments · Fixed by #538

Comments

@chaoran
Copy link
Contributor

chaoran commented Jul 11, 2013

The date object inserted into database, and what is retrieved from the database is different.

var mysql = require('mysql')
  , assert = require('assert');

var conn= mysql.createConnection({
  host: 'localhost',
  user: 'root',
  database: 'test'
});

conn.connect();

conn.query(
  'CREATE TABLE IF NOT EXISTS datetime_bug (id SERIAL, created_at DATETIME(3))', 
  function(err) {
    if (err) throw err;

    var date = new Date();

    conn.query('INSERT INTO datetime_bug SET ?', { 
      created_at: date
    }, function(err, result) {
      if (err) throw err;

      var id = result.insertId;

      conn.query('SELECT * FROM datetime_bug WHERE ?', { id: id }, function(err, row) {
        if (err) throw err;
        conn.end();
        assert.equal(date, row[0].created_at);
      });
    });
  }
);

This throws: AssertionError: "2013-07-11T16:28:26.218Z" == "2013-07-11T16:28:26.000Z"

@wmertens
Copy link

@dougwilson
Copy link
Member

@chaoran what version of MySQL server are you connecting to?

@wmertens MySQL cannot store sub-second resolution in DATETIME until MySQL 5.6.4. Unless @chaoran is using MySQL 5.6.4 or higher, than the point is moot for him.

@chaoran
Copy link
Contributor Author

chaoran commented Jul 11, 2013

@dougwilson Sorry. I should mention that I'm using mysql 5.6.12.

@dougwilson
Copy link
Member

Thanks, @chaoran. So that means it would be nice to get this library to include milliseconds in the date stringification (by default? by a switch?).

@chaoran
Copy link
Contributor Author

chaoran commented Jul 11, 2013

@dougwilson, I think it should be added by default. The milliseconds part is harmless because mysql will silently ignore that part if it does not support fraction of time.

@dougwilson
Copy link
Member

Though MySQL doesn't ignore it, it produces a warning, and when strict is turned on, it will be fatal, which is why it wasn't included in the library before, I think.

@chaoran
Copy link
Contributor Author

chaoran commented Jul 11, 2013

@dougwilson Really? It doesn't complain at all for me.

mysql> SELECT @@SESSION.sql_mode;
+--------------------+
| @@SESSION.sql_mode |
+--------------------+
| STRICT_ALL_TABLES  |
+--------------------+
1 row in set (0.00 sec)

mysql> insert into datetime_bug SET created_at='2013-12-31 12:31:33.123';
Query OK, 1 row affected (0.00 sec)

mysql> select * from datetime_bug ORDER BY id DESC LIMIT 1;
+----+---------------------+
| id | created_at          |
+----+---------------------+
| 10 | 2013-12-31 12:31:33 |
+----+---------------------+
1 row in set (0.00 sec)

The created_at column above is of the plain DATETIME type, not the new DATETIME(3) type.

@dresende
Copy link
Collaborator

If the milisecond support could be checked in server info packet on connection, it could be automatically added if supported. But I'm not sure the server does this.

@dougwilson
Copy link
Member

Actually, I just ran what @chaoran did on 5.1.70 and it does indeed not issue any warnings or error on strict mode. @dresende that means you can just add in the milliseconds in the date string stringification and it should definitely be perfectly fine on all versions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

4 participants