[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
DATETIME
, DATE
, and TIMESTAMP
Types
The DATETIME
, DATE
, and TIMESTAMP
types are related.
This section describes their characteristics, how they are similar, and how
they differ.
The DATETIME
type is used when you need values that contain both date
and time information. MySQL retrieves and displays DATETIME
values in 'YYYY-MM-DD HH:MM:SS'
format. The supported range is
'1000-01-01 00:00:00'
to '9999-12-31 23:59:59'
. ("Supported"
means that although earlier values might work, there is no guarantee that
they will.)
The DATE
type is used when you need only a date value, without a time
part. MySQL retrieves and displays DATE
values in
'YYYY-MM-DD'
format. The supported range is '1000-01-01'
to
'9999-12-31'
.
The TIMESTAMP
column type has varying properties and behavior,
depending on the MySQL version and the SQL mode the server is running in.
TIMESTAMP
behavior when running in MAXDB
mode
When MySQL is running in MAXDB
mode, TIMESTAMP
behaves like
DATETIME
. No automatic updating of TIMESTAMP
columns occurs,
as described in the following paragraphs. MySQL can be run in MAXDB
mode as of version 4.1.1. See section 5.2.1 mysqld
Command-line Options.
TIMESTAMP
behavior when not running in MAXDB
mode
The TIMESTAMP
column type provides a type that you can use to
automatically mark INSERT
or UPDATE
operations with the current
date and time. If you have multiple TIMESTAMP
columns, only the first
one is updated automatically.
Automatic updating of the first TIMESTAMP
column occurs under any of
the following conditions:
INSERT
or
LOAD DATA INFILE
statement.
UPDATE
statement and some
other column changes value. (Note that an UPDATE
that sets a column
to the value it already has will not cause the TIMESTAMP
column to be
updated, because if you set a column to its current value, MySQL
ignores the update for efficiency.)
TIMESTAMP
column to NULL
.
TIMESTAMP
columns other than the first may also be set to the current
date and time. Just set the column to NULL
or to NOW()
.
You can set any TIMESTAMP
column to a value different from the current
date and time by setting it explicitly to the desired value. This is true
even for the first TIMESTAMP
column. You can use this property if,
for example, you want a TIMESTAMP
to be set to the current date and
time when you create a row, but not to be changed whenever the row is updated
later:
TIMESTAMP
column explicitly to its current value.
On the other hand, you may find it just as easy to use a DATETIME
column that you initialize to NOW()
when the row is created and
leave alone for subsequent updates.
TIMESTAMP
properties when running in MAXDB
mode
When MySQL is running in MAXDB
mode, TIMESTAMP
is identical with
DATETIME
. It uses the same format to store and display values, and it
has the same range. MySQL can be run in MAXDB
mode as of version 4.1.1.
See section 5.2.1 mysqld
Command-line Options.
TIMESTAMP
properties as of MySQL 4.1 when not running in MAXDB
mode
In MySQL 4.1.0, TIMESTAMP
columns are stored and displayed in the same
format as DATETIME
columns. This also means that they cannot be narrowed
or widened in the ways described in the following paragraphs. In other words,
you cannot use TIMESTAMP(2)
, TIMESTAMP(4)
, etc. Other than that,
the properties are the same as in previous MySQL versions.
TIMESTAMP
properties prior to MySQL 4.1
TIMESTAMP
values may range from the beginning of 1970 to sometime in
the year 2037, with a resolution of one second. Values are displayed as
numbers.
The format in which MySQL retrieves and displays TIMESTAMP
values depends on the display size, as illustrated by the following table. The
`full' TIMESTAMP
format is 14 digits, but TIMESTAMP
columns may
be created with shorter display sizes:
Column type | Display format |
TIMESTAMP(14) | YYYYMMDDHHMMSS |
TIMESTAMP(12) | YYMMDDHHMMSS |
TIMESTAMP(10) | YYMMDDHHMM |
TIMESTAMP(8) | YYYYMMDD |
TIMESTAMP(6) | YYMMDD |
TIMESTAMP(4) | YYMM |
TIMESTAMP(2) | YY |
All TIMESTAMP
columns have the same storage size, regardless of
display size. The most common display sizes are 6, 8, 12, and 14. You can
specify an arbitrary display size at table creation time, but values of 0 or
greater than 14 are coerced to 14. Odd-valued sizes in the range from 1 to
13 are coerced to the next higher even number.
Note: From version 4.1, TIMESTAMP
is returned as a string with
the format 'YYYY-MM-DD HH:MM:SS'
and different timestamp lengths are
no longer supported.
You can specify DATETIME
, DATE
, and TIMESTAMP
values using
any of a common set of formats:
'YYYY-MM-DD HH:MM:SS'
or 'YY-MM-DD
HH:MM:SS'
format. A "relaxed" syntax is allowed--any punctuation
character may be used as the delimiter between date parts or time parts.
For example, '98-12-31 11:30:45'
, '98.12.31 11+30+45'
,
'98/12/31 11*30*45'
, and '98@12@31 11^30^45'
are
equivalent.
'YYYY-MM-DD'
or 'YY-MM-DD'
format.
A "relaxed" syntax is allowed here, too. For example, '98-12-31'
,
'98.12.31'
, '98/12/31'
, and '98@12@31'
are
equivalent.
'YYYYMMDDHHMMSS'
or
'YYMMDDHHMMSS'
format, provided that the string makes sense as a
date. For example, '19970523091528'
and '970523091528'
are
interpreted as '1997-05-23 09:15:28'
, but '971122129015'
is
illegal (it has a nonsensical minute part) and becomes '0000-00-00
00:00:00'
.
'YYYYMMDD'
or 'YYMMDD'
format, provided that the string makes sense as a date. For example,
'19970523'
and '970523'
are interpreted as
'1997-05-23'
, but '971332'
is illegal (it has nonsensical month
and day parts) and becomes '0000-00-00'
.
YYYYMMDDHHMMSS
or YYMMDDHHMMSS
format, provided that the number makes sense as a date. For example,
19830905132800
and 830905132800
are interpreted as
'1983-09-05 13:28:00'
.
YYYYMMDD
or YYMMDD
format, provided that the number makes sense as a date. For example,
19830905
and 830905
are interpreted as '1983-09-05'
.
DATETIME
, DATE
, or TIMESTAMP
context, such as
NOW()
or CURRENT_DATE
.
Illegal DATETIME
, DATE
, or TIMESTAMP
values are converted
to the "zero" value of the appropriate type ('0000-00-00 00:00:00'
,
'0000-00-00'
, or 00000000000000
).
For values specified as strings that include date part delimiters, it is not
necessary to specify two digits for month or day values that are less than
10
. '1979-6-9'
is the same as '1979-06-09'
. Similarly,
for values specified as strings that include time part delimiters, it is not
necessary to specify two digits for hour, minute, or second values that are
less than 10
. '1979-10-30 1:2:3'
is the same as
'1979-10-30 01:02:03'
.
Values specified as numbers should be 6, 8, 12, or 14 digits long. If the
number is 8 or 14 digits long, it is assumed to be in YYYYMMDD
or
YYYYMMDDHHMMSS
format and that the year is given by the first 4
digits. If the number is 6 or 12 digits long, it is assumed to be in
YYMMDD
or YYMMDDHHMMSS
format and that the year is given by the
first 2 digits. Numbers that are not one of these lengths are interpreted
as though padded with leading zeros to the closest length.
Values specified as non-delimited strings are interpreted using their length
as given. If the string is 8 or 14 characters long, the year is assumed to
be given by the first 4 characters. Otherwise, the year is assumed to be
given by the first 2 characters. The string is interpreted from left to
right to find year, month, day, hour, minute, and second values, for as many
parts as are present in the string. This means you should not use strings
that have fewer than 6 characters. For example, if you specify '9903'
,
thinking that will represent March, 1999, you will find that MySQL
inserts a "zero" date into your table. This is because the year and month
values are 99
and 03
, but the day part is completely missing, so
the value is not a legal date. However, as of MySQL 3.23, you can explicitly
specify a value of zero to represent missing month or day parts. For example,
you can use '990300'
to insert the value '1999-03-00'
.
TIMESTAMP
columns store legal values using the full precision with
which the value was specified, regardless of the display size. This has
several implications:
TIMESTAMP(4)
or TIMESTAMP(2)
. Otherwise, the value will not
be a legal date and 0
will be stored.
ALTER TABLE
to widen a narrow TIMESTAMP
column,
information will be displayed that previously was "hidden".
TIMESTAMP
column does not cause information to
be lost, except in the sense that less information is shown when the values
are displayed.
TIMESTAMP
values are stored to full precision, the only
function that operates directly on the underlying stored value is
UNIX_TIMESTAMP()
. Other functions operate on the formatted retrieved
value. This means you cannot use functions such as HOUR()
or
SECOND()
unless the relevant part of the TIMESTAMP
value is
included in the formatted value. For example, the HH
part of a
TIMESTAMP
column is not displayed unless the display size is at least
10, so trying to use HOUR()
on shorter TIMESTAMP
values
produces a meaningless result.
You can to some extent assign values of one date type to an object of a different date type. However, there may be some alteration of the value or loss of information:
DATE
value to a DATETIME
or TIMESTAMP
object, the time part of the resulting value is set to '00:00:00'
,
because the DATE
value contains no time information.
DATETIME
or TIMESTAMP
value to a DATE
object, the time part of the resulting value is deleted, because the
DATE
type stores no time information.
DATETIME
, DATE
, and TIMESTAMP
values all can be specified using the same set of formats, the types do not
all have the same range of values. For example, TIMESTAMP
values
cannot be earlier than 1970
or later than 2037
. This means
that a date such as '1968-01-01'
, while legal as a DATETIME
or
DATE
value, is not a valid TIMESTAMP
value and will be
converted to 0
if assigned to such an object.
Be aware of certain pitfalls when specifying date values:
'10:11:12'
might look like a time value
because of the `:' delimiter, but if used in a date context will be
interpreted as the year '2010-11-12'
. The value '10:45:15'
will be converted to '0000-00-00'
because '45'
is not a legal
month.
00-31
, months 00-12
, years 1000-9999
.
Any date not within this range will revert to 0000-00-00
.
Please note that this still allows you to store invalid dates such as
2002-04-31
. It allows web applications to store data from a form
without further checking. To ensure a date is valid, perform a check in
your application.
00-69
are converted to 2000-2069
.
70-99
are converted to 1970-1999
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |