Skip navigation links
10.3.2 The TIME Type »
Section Navigation      [Toggle]

10.3.1.1. TIMESTAMP Properties

TIMESTAMP columns are displayed using the same format as DATETIME columns, 'YYYY-MM-DD HH:MM:SS'.

Note

In older versions of MySQL (prior to 4.1), the properties of the TIMESTAMP data type differed significantly in several ways from what is described in this section (see the MySQL 3.23, 4.0, 4.1 Reference Manual for details); these include syntax extensions which are deprecated in MySQL 5.1, and no longer supported in MySQL 5.5. This has implications for performing a dump and restore or replicating between MySQL Server versions. If you are using columns that are defined using the old TIMESTAMP(N) syntax, see Section 2.19.1.2, “Upgrading from MySQL 4.1 to 5.0”, prior to upgrading to MySQL 5.1 or later.

TIMESTAMP values are converted from the current time zone to UTC for storage, and converted back from UTC to the current time zone for retrieval. (This does not occur for other types such as DATETIME.) By default, the current time zone for each connection is the server's time. The time zone can be set on a per-connection basis. As long as the time zone setting remains constant, you get back the same value you store. If you store a TIMESTAMP value, and then change the time zone and retrieve the value, the retrieved value is different from the value you stored. This occurs because the same time zone was not used for conversion in both directions. The current time zone is available as the value of the time_zone system variable. For more information, see Section 9.6, “MySQL Server Time Zone Support”.

The TIMESTAMP data type offers automatic initialization and updating. You can choose whether to use these properties and which column should have them:

  • For one TIMESTAMP column in a table, you can assign the current timestamp as the default value and the auto-update value. The current timestamp can be the default value for initializing the column, for the auto-update value, or both. However, it is not possible to have the current timestamp be the default value for one column and the auto-update value for another column.

  • Any TIMESTAMP column in a table can be used as the one that is initialized to the current date and time, or updated automatically. This need not be the first TIMESTAMP column.

  • The auto-update TIMESTAMP column, if there is one, is automatically updated to the current timestamp when the value of any other column in the row is changed from its current value. If all other columns are set to their current values, the TIMESTAMP column does not change. Automatic updating does not apply if the TIMESTAMP column is explicitly assigned a value other than NULL.

  • If a DEFAULT value is specified for the first TIMESTAMP column in a table, it is not ignored. The default can be CURRENT_TIMESTAMP or a constant date and time value.

  • In a CREATE TABLE statement, the first TIMESTAMP column can be declared in any of the following ways:

    • With both DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP clauses, the column has the current timestamp for its default value, and is automatically updated.

    • With neither DEFAULT nor ON UPDATE clauses, it is the same as DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP.

    • With a DEFAULT CURRENT_TIMESTAMP clause and no ON UPDATE clause, the column has the current timestamp for its default value but is not automatically updated.

    • With no DEFAULT clause and with an ON UPDATE CURRENT_TIMESTAMP clause, the column has a default of 0 and is automatically updated.

    • With a constant DEFAULT value, the column has the given default and is not automatically initialized to the current timestamp. If the column also has an ON UPDATE CURRENT_TIMESTAMP clause, it is automatically updated; otherwise, it has a constant default and is not automatically updated.

    In other words, you can use the current timestamp for both the initial value and the auto-update value, or either one, or neither. (For example, you can specify ON UPDATE to enable auto-update without also having the column auto-initialized.) The following column definitions demonstrate each possibility:

    • Auto-initialization and auto-update: 

      col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

    • Auto-initialization only: 

      col_name TIMESTAMP DEFAULT CURRENT_TIMESTAMP

    • Auto-update only: 

      col_name TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP

    • Neither: 

      col_name TIMESTAMP DEFAULT 0

  • To specify automatic default or updating for a TIMESTAMP column other than the first one, you must suppress the automatic initialization and update behaviors for the first TIMESTAMP column by explicitly assigning it a constant DEFAULT value (for example, DEFAULT 0 or DEFAULT '2003-01-01 00:00:00'). Then, for the other TIMESTAMP column, the rules are the same as for the first TIMESTAMP column, except that if you omit both of the DEFAULT and ON UPDATE clauses, no automatic initialization or updating occurs.

    Example: 

    CREATE TABLE t (
    ts1 TIMESTAMP DEFAULT 0,
    ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP
                  ON UPDATE CURRENT_TIMESTAMP);

  • CURRENT_TIMESTAMP or any of its synonyms (CURRENT_TIMESTAMP(), NOW(), LOCALTIME, LOCALTIME(), LOCALTIMESTAMP, or LOCALTIMESTAMP()) can be used in the DEFAULT and ON UPDATE clauses. They all mean “the current timestamp.” UTC_TIMESTAMP is not permitted. Its range of values does not align with those of the TIMESTAMP column except when the current time zone is UTC.

  • The order of the DEFAULT and ON UPDATE clauses does not matter. If both DEFAULT and ON UPDATE are specified for a TIMESTAMP column, either can precede the other. For example, these statements are equivalent: 

    CREATE TABLE t (ts TIMESTAMP);
CREATE TABLE t (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP
                             ON UPDATE CURRENT_TIMESTAMP);
CREATE TABLE t (ts TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
                             DEFAULT CURRENT_TIMESTAMP);
Note

The examples that use DEFAULT 0 will not work if the NO_ZERO_DATE SQL mode is enabled because that mode causes “zero” date values (specified as 0, '0000-00-00, or '0000-00-00 00:00:00') to be rejected. Be aware that the TRADITIONAL SQL mode includes NO_ZERO_DATE.

TIMESTAMP columns are NOT NULL by default, cannot contain NULL values, and assigning NULL assigns the current timestamp. However, a TIMESTAMP column can be permitted to contain NULL by declaring it with the NULL attribute. In this case, the default value also becomes NULL unless overridden with a DEFAULT clause that specifies a different default value. DEFAULT NULL can be used to explicitly specify NULL as the default value. (For a TIMESTAMP column not declared with the NULL attribute, DEFAULT NULL is illegal.) If a TIMESTAMP column permits NULL values, assigning NULL sets it to NULL, not to the current timestamp.

The following table contains several TIMESTAMP columns that permit NULL values: 

CREATE TABLE t
(
  ts1 TIMESTAMP NULL DEFAULT NULL,
  ts2 TIMESTAMP NULL DEFAULT 0,
  ts3 TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP
);

Note that a TIMESTAMP column that permits NULL values will not take on the current timestamp except under one of the following conditions:

In other words, a TIMESTAMP column defined as NULL will auto-initialize only if it is created using a definition such as the following: 

CREATE TABLE t (ts TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP);

Otherwise—that is, if the TIMESTAMP column is defined to permit NULL values but not using DEFAULT CURRENT_TIMESTAMP, as shown here… 

CREATE TABLE t1 (ts TIMESTAMP NULL DEFAULT NULL);
CREATE TABLE t2 (ts TIMESTAMP NULL DEFAULT '0000-00-00 00:00:00');

…then you must explicitly insert a value corresponding to the current date and time. For example: 

INSERT INTO t1 VALUES (NOW());
INSERT INTO t2 VALUES (CURRENT_TIMESTAMP);
Note

The MySQL server can be run with the MAXDB SQL mode enabled. In this case, TIMESTAMP is identical with DATETIME. If this mode is enabled at the time that a table is created, TIMESTAMP columns are created as DATETIME columns. As a result, such columns use DATETIME display format, have the same range of values, and there is no automatic initialization or updating to the current date and time. See Section 5.1.6, “Server SQL Modes”.

Copyright © 1997, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices

User Comments

Posted by Geoffrey Hoffman on December 9 2007 12:46am[Delete] [Edit]

The only way to have more than one TIMESTAMP column, when one is declared with either DEFAULT CURRENT_TIMESTAMP or ON UPDATE CURRENT_TIMESTAMP or both, is to force the other timestamp column default to a valid timestamp value, such as 20070101000000.

I believe this is due to a TIMESTAMP column without a declared default uses the CURRENT_TIMESTAMP and thus throws this error

#1293 - Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause.

even though it appears you are only trying to use it on one column.

Posted by m m on January 27 2008 11:20am[Delete] [Edit]

nope, all you have to do is to declare TIMESTAMP column with DEFAULT CURRENT_TIMESTAMP before any other TIMESTAMP columns.

short explanation from someone who knows why is this so, would be nice.

Posted by Dan Barlow on January 28 2008 7:56pm[Delete] [Edit]

`user_created_date` timestamp default CURRENT_TIMESTAMP COMMENT 'creation timestamp',
`user_updated_date` timestamp default '20070101000000' COMMENT 'edit timestamp',

This will work. If you try to set the second timestamp field to ON UPDATE CURRENT_TIMESTAMP it will then report
#1293 - Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause
It seems to me the function of having both a creation timestamp set once by the default and an edit timestamp set repeatedly on update is NOT SUPPORTED by MySQL.

Posted by Michael Moussa on February 14 2008 6:09pm[Delete] [Edit]

You do not have to default it to some constant, you can also default it to NULL, like so...
`creationtime` timestamp NULL default NULL,
`lastupdate` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,

An explanation as to why they cannot have one column default to CURRENT_TIMESTAMP on creation and another column be the CURRENT_TIMESTAMP on update would be nice. I find myself in creation of many tables where I need this functionality on two separate columns.

Posted by mari a on March 12 2008 10:36pm[Delete] [Edit]

"TIMESTAMP columns are NOT NULL by default, cannot contain NULL values, and assigning NULL assigns the current timestamp."

What I do, is declare my created_at column as NOT NULL, then assign the column as NULL when I do the insert.. which populates it with the current timestamp.

Then on updates, the second timestamp column with the ON UPDATE...etc updates on it's own. However, the update code must not alter the created_at column at all (obviously).

created_at timestamp NOT NULL default '0000-00-00 00:00:00'
updated_at timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP

INSERT INTO table(created_at,updated_at) VALUES (NULL,NULL);

populates BOTH columns with same timestamp for creation.

Posted by sanjuro tsubaki on March 18 2008 2:15pm[Delete] [Edit]

If the value(s) you are trying to update are identical, MySQL will not auto-update the timestamp alone. You will have to use NOW() instead.

Posted by Ashley Raiteri on July 5 2008 7:54pm[Delete] [Edit]

These last two posts are the only mechanism that worked for us.
In any system, hand coded, phpmyadmin, mysql query browser or otherwise :

`created` timestamp NOT NULL default '0000-00-00 00:00:00',
`modified` timestamp NOT NULL default CURRENT_TIMESTAMP on update NOW(),

although, phpmyadmin exports this out without the NOW, replacing it with CURRENT_TIMESTAMP instead.

Posted by Chris Heath on July 29 2008 3:32am[Delete] [Edit]

Note that using CURRENT_TIMESTAMP explicitly in an INSERT or UPDATE does not always insert the current timestamp. The only correct way is to insert NULL or to omit the timestamp column entirely.

With an explicit CURRENT_TIMESTAMP, MySQL converts the current timestamp to YYYY-MM-DD HH-MM-SS format and then back to a timestamp, which is a lossy conversion if you are in a timezone with daylight savings.

Example to demonstrate: (assumes US Eastern Time)
\! date 110400592007.59
Sun Nov 4 00:59:59 EDT 2007
\! sleep 2
CREATE TABLE test (id int, t timestamp);
INSERT INTO test VALUES (1, NULL), (2, CURRENT_TIMESTAMP);
SELECT test.*, UNIX_TIMESTAMP(t) FROM test;
+------+---------------------+-------------------+
| id | t | UNIX_TIMESTAMP(t) |
+------+---------------------+-------------------+
| 1 | 2007-11-04 01:00:01 | 1194152401 |
| 2 | 2007-11-04 01:00:01 | 1194156001 |
+------+---------------------+-------------------+

The second row is wrong: the unix timestamp is 1 hour (3600 seconds) later, a result of a lossy round-trip conversion.

Posted by michael splendid on August 27 2008 5:40pm[Delete] [Edit]

using ALTER to add a TIMESTAMP column with the DEFAULT CURRENT_TIMESTAMP attribute, will not add the current TIMSTAMP to that column (as expected)
Mike Trader

Posted by Bogdan Gusiev on May 11 2009 4:42pm[Delete] [Edit]

Here is a solution how to make both update and create timestamps in mysql in one table:
http://gusiev.com/2009/04/update-and-create-timestamps-with-mysql/

Posted by Stefan Zielinski on May 11 2009 11:07pm[Delete] [Edit]

The example in Bogdan Gusiev's link is essentially the same as from the 5th post above ("Posted by mari a on March 12 2008 10:36pm"), and while it does work, it can also be achieved by declaring the following table:

CREATE TABLE test.table (
`row_inserted` TIMESTAMP NULL,
`row_updated` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)

...and then specifying CURRENT_TIMESTAMP explicitly in the insert statement:

INSERT INTO test.table (row_inserted) VALUES (CURRENT_TIMESTAMP)

...all of these solutions require that the code doing the insert explicitly set a value for the created / inserted timestamp column - whether it is NULL or CURRENT_TIMESTAMP - there doesn't seem to be a way for MySQL to handle this implicitly.

Ideally, these columns would never need to be explicitly referenced by any insert or update query, and instead be set automatically, with a declaration like this:

CREATE TABLE test.table (
`row_inserted` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
`row_updated` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)

...and I'm not sure why MySQL chose not to support this - it doesn't seem like there should be any real technical limitation that prevents it.

Posted by Rob Desbois on July 29 2009 8:24am[Delete] [Edit]

We recently modified a DATETIME column to be of type TIMESTAMP as we wanted to take advantage of the timezone-related functionality, but found there's no way to create a TIMESTAMP column with no default and no 'on update' value.

The 2-step process to achieve this is as follows:
CREATE TABLE foo (ts TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP);
ALTER TABLE foo ALTER ts DROP DEFAULT;

Posted by Joseph Piché on August 4 2009 2:15pm[Delete] [Edit]

It may help someone that depending on table structure and the amount of data in the table, if you need to ORDER BY a TIMESTAMP column, it may speed up the query by using ORDER BY UNIX_TIMESTAMP(`field`).

Posted by Nasantsogt Baasanjav on May 9 2010 1:06pm[Delete] [Edit]

I've managed the issue of having tables with create/update timestamps with the help of triggers defined on DATETIME columns (instead of TIMESTAMP):

CREATE TABLE table (
id INT(11) NOT NULL auto_increment,
value VARCHAR(32) DEFAULT NULL,
created_at DATETIME DEFAULT NULL,
updated_at DATETIME DEFAULT NULL
)

CREATE TRIGGER table_created_at
BEFORE INSERT ON table
FOR EACH ROW
SET NEW.created_at = UTC_TIMESTAMP, NEW.updated_at = UTC_TIMESTAMP

CREATE_TRIGGER table_updated_at
BEFORE UPDATE ON table
FOR EACH ROW
SET NEW.updated_at = UTC_TIMESTAMP, NEW.created_at = OLD.created_at

This way i'm not forced to set explicitly NULL on those fields, i just omit them entirely. Even more, any explicit value specified on those fields in insert/update SQL statements is simply ignored (it is exactly the purpose of the "NEW.created_at = OLD.created_at" segment in the second trigger: to avoid being overwritten).

Secondly, i could choose any function, not just NOW or CURRENT_TIMESTAMP, for example UTC_TIMESTAMP or anything else. In the particular case of a project i worked on, i prefered to deal directly with UTC times and let timezone issues be managed on geographically distributed (RIA) clients..

Posted by Shelby Moore on August 18 2010 3:38am[Delete] [Edit]

Here is how I achieve created and updated timestamps:

ChangeDate timestamp(14) NOT NULL,
CreationDate timestamp(14) NOT NULL,

where ChangeDate is the very first column in the table (maybe it only needs to be the first timestamp in the table).

Then on record creation, I set both timestamps to NOW(). On record update, I do not assign any value to the timestamps. The ChangeDate is automatically updated.

If I want to update the record and not change the ChangeDate automatically, I set it to itself as follows:

UPDATE user SET ChangeDate = ChangeDate, ...

Posted by Shelby Moore on August 18 2010 3:43am[Delete] [Edit]

I believe the reason other commenters above were having problems is because they were declaring the automatically updated timestamp, to be the 2nd timestamp in the table. The automatically updated timestamp must be the 1st timestamp (maybe column?) in the table.

Posted by Sam Chet on October 4 2010 5:11pm[Delete] [Edit]

"using ALTER to add a TIMESTAMP column with the DEFAULT CURRENT_TIMESTAMP attribute, will not add the current TIMSTAMP to that column (as expected)
Mike Trader"

Check the bug report and discussion on
http://bugs.mysql.com/bug.php?id=17392&thanks=3&notify=199

Posted by M Hamed Ar on September 28 2011 10:59am[Delete] [Edit]

It seems the suggestion of Nasantsogt Baasanjav is the most perfect solution.

The only drawback for this solution is there is no examination for record change. this means even if the value of other columns of a record is not changed at all, the updated_at field is updated.

I suggest to make an automatic check in the update trigger to improve this workaround.

Posted by Jeffrey Kurtock on February 4 2012 11:35pm[Delete] [Edit]

Use of current_timestamp is a trap, and should always be avoided.

Whenever you might think you want current_timestamp, you can always use:
INSERT INTO tablename SET [..., ...], record_added=now()
or
UPDATE tablename SET [..., ...], record_updated=now()

This is self-documenting; you don't have to guess how the datetime fields are set.

The other suggestions made all rely on undocumented side-effects of MySQL (assigning null to a field?!), or complex add-ons like Triggers. Remember: if it isn't documented, you can't count on it happening the same way on the next release.

But for my money, the biggest reason to avoid current_timestamp is how it runs without any control by you, the developer. Someday you're going to get a call at 3am, and you'll quickly realize you can fix the problem by changing all the "Pmt-Type" (or whatever) fields to lower-case. This would be a simple fix using something like phpMyAdmin, but if you do it your "current_timestamp" fields will all update and you can't stop it. (Well, you can avoid it, if you remember in advance, but it is a real pain.)

Production code doesn't rely on people entering SQL "by hand," so you have no need to force yourself to update a record_updated field. Just use "=now()" in your code instead and you will be safe.

Add your own comment.