The TIME Type +---------------------+---------------------+ | col | ut | +---------------------+---------------------+ | 2020-01-01 10:10:10 | 2020-01-01 15:10:10 | | 2019-12-31 23:40:10 | 2020-01-01 04:40:10 | | 2020-01-01 13:10:10 | 2020-01-01 18:10:10 | | 2020-01-01 10:10:10 | 2020-01-01 15:10:10 | | 2020-01-01 04:40:10 | 2020-01-01 09:40:10 | | 2020-01-01 18:10:10 | 2020-01-01 23:10:10 | +---------------------+---------------------+ For complete information regarding syntax and additional examples, see the description of the  CAST() function. Be aware of certain properties of date value interpretation in MySQL: The only delimiter recognized between a date and time part and a fractional seconds part is the decimal point. MySQL retrieves and displays  TIME  values in  ’hh:mm:ss’  format (or  ’hhh:mm:ss’  format for large hours values).  TIME  values may range from  ’-838:59:59’  to  ’838:59:59’ . The hours part may be so large because the  TIME  type can be used not only to represent a time of day (which must be less than 24 hours), but also elapsed time or a time interval between two events (which may be much greater than 24 hours, or even negative). MySQL recognizes  TIME  values in several formats, some of which can include a trailing fractional seconds part in up to microseconds (6 digits) precision. See Section 9.1.3, “Date and Time Literals” . For information about fractional seconds support in MySQL, see Section 11.2.6, “Fractional Seconds in Time Values” . In particular, any fractional part in a value inserted into a  TIME  column is stored rather than 2027 11.2.3 The TIME Type •MySQL permits a “relaxed”  format for values specified as strings, in which any punctuation character may be used as the delimiter between date parts or time parts. In some cases, this syntax can be deceiving. For example, a value such as  ’10:11:12’  might look like a time value because of the  : , but is interpreted as the year  ’2010-11-12’  if used in date context. The value  ’10:45:15’  is converted to  ’0000-00-00’  because  ’45’  is not a valid month. •The server requires that month and day values be valid, and not merely in the range 1 to 12 and 1 to 31, respectively. With strict mode disabled, invalid dates such as  ’2004-04-31’  are converted to ’0000-00-00’  and a warning is generated. With strict mode enabled, invalid dates generate an error. To permit such dates, enable  ALLOW_INVALID_DATES . See Section 5.1.11, “Server SQL Modes” , for more information. •MySQL does not accept  TIMESTAMP  values that include a zero in the day or month column or values that are not a valid date. The sole exception to this rule is the special “zero”  value  ’0000-00-00 00:00:00’ , if the SQL mode permits this value. The precise behavior depends on which if any of strict SQL mode and the  NO_ZERO_DATE  SQL mode are enabled; see Section 5.1.11, “Server SQL Modes” . •Dates containing 2-digit year values are ambiguous because the century is unknown. MySQL interprets 2-digit year values using these rules: •Year values in the range  00-69  become  2000-2069 . •Year values in the range  70-99  become  1970-1999 . See also Section 11.2.8, “2-Digit Years in Dates” .