They both look the same, have roughly the same use. Nevertheless, they differ in many respects. I’ll note the difference, and note a few pitfalls and peculiarities.<\/p>\n
TIMESTAMP<\/strong> starts with the epoch<\/a>, ‘1970-01-01 00:00:01’<\/strong> UTC and ends with ‘2038-01-19 03:14:07’<\/strong> UTC. This is all very nice today, and may actually hold up till our retirement, but the younger readers may yet have to deal with the Bug2K+38<\/strong>\u2122, certain to arrive.<\/p>\n DATETIME<\/strong> starts with ‘1000-01-01 00:00:00’<\/strong> and lasts up to ‘9999-12-31 23:59:59’<\/strong>. More on that later.<\/p>\n In respect of range, your current event logs may well use a TIMESTAMP<\/strong> value, while your grandfather’s and granddaughter’s birth dates may require DATETIME<\/strong>.<\/p>\n In general I would suggest that anything that relates to now<\/em>, can be a TIMESTAMP<\/strong>. A new entry is added? It is added now<\/em>. It can be represented by a TIMESTAMP<\/strong>. Anything has an expiry time of a few minutes, perhaps a few days or a month? You’ll be safe using it up till late 2037<\/strong>. Anything else had better use a DATETIME<\/strong>. In particular, dates relating to issues such as birth, insurance, the market etc. fall into this category.<\/p>\n History<\/em>, however, does not even hold up with DATETIME<\/strong>. Rome fell long before MIN(DATETIME)<\/strong>. You will have to manage your own. Not even YEAR<\/strong> will help you out.<\/p>\n TIMESTAMP<\/strong> makes for 4<\/strong> bytes. DATETIME<\/strong> makes for 8<\/strong> bytes. Now that we have this behind us, let’s see why.<\/p>\n A TIMESTAMP<\/strong> is merely the number of elapsed seconds since the epoch<\/em>. It is a number. Not only is this a number, it is an incrementing number, and without gaps. Ever ascending. It actually equals the UNIX_TIMESTAMP()<\/strong> function.<\/p>\n A DATETIME<\/strong> is more of an oddity. From the manual:<\/p>\n Huh?<\/em><\/p>\n There’s nothing sequential about a DATETIME<\/strong>. The value which follows 20110307095159<\/strong> is 20110307095200<\/strong>. It’s like the string representation without any delimiters. See the following (ignore the fraction, it’s not really there):<\/p>\n The implication of this internal representation is that conversions must be made back and forth. When you want to add 5<\/strong> seconds to a DATETIME<\/strong>, MySQL cannot simply add 5<\/strong> to some number, but must make for a more complicated calculation.<\/p>\n Now here’s a question: why does DATETIME<\/strong> start with ‘1000-01-01 00:00:00’<\/strong>? Can you provide with a convincing argument? The only argument I can find is hardly convincing.<\/p>\n Did you ever need to type in a password with your phone? Say, for your Credit Card company, or your Bank? Did you get recorded instructions saying “You must type six digits. You must not repeat the same digits three successive times<\/em>“? That’s somewhat nice, and probably a good advice. Did you ever get told “The first digit must not be 0<\/strong><\/em>“? That’s just stupid<\/em>. This means we’re giving up on 100,000<\/strong> valid passwords, thereby reducing our search space by 10%<\/strong>!<\/p>\n I suspect in both cases the reasoning is the same: if you start with a 0<\/strong>, and we represent it as a number, it won’t make up for the same number of digits we intended it to.<\/p>\n In the case of your Credit Card company, there is no excuse. What’s the problem with padding with zeros till you make those six digits?<\/p>\n In the case of MySQL’s DATETIME<\/strong>, I can see a weak reasoning. Read this page on the docs<\/a> to find out that a DATETIME<\/strong> can be represented in many forms, and can be automatically deduced from a string in many formats. Both strings ‘110307095100’<\/strong> and ‘20110307095100’<\/strong> make for the same DATETIME<\/strong> value. It is based on the number of characters in your text, that the parsing decides how to act.<\/p>\n The fact the first year is 1000<\/strong> makes the number of digits predictable.<\/p>\n I don’t see why I should care about automatically converting texts of different formats to a DATETIME<\/strong>. As a programmer, I’m perfectly content with strict typing. I don’t mind passing around only texts of the form ‘YYYY-MM-DD HH:MM:SS’<\/strong> (or, better yet, passing date objects and letting my connector do the translation). Moreover, I prefer it that way! It makes me feel safer, that I haven’t passed a wrong text by mistake, to be silently accepted.<\/p>\n For this reason I don’t like the idea of losing the ability to use DATETIME<\/strong> on 1,000<\/strong> lost years. As far as I can tell, this is a MySQL specific issue; there is no ANSI SQL<\/strong> for DATETIME<\/strong>.<\/p>\n [UPDATE<\/strong>:\u00a0 Sheeri notes<\/a> the biggest difference: DATETIME<\/strong> does not support time zones. A good discussion is also available on OurSQL<\/a>]<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" They both look the same, have roughly the same use. Nevertheless, they differ in many respects. I’ll note the difference, and note a few pitfalls and peculiarities. Range TIMESTAMP starts with the epoch, ‘1970-01-01 00:00:01’ UTC and ends with ‘2038-01-19 03:14:07’ UTC. This is all very nice today, and may actually hold up till our […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[5],"tags":[18],"class_list":["post-3361","post","type-post","status-publish","format-standard","hentry","category-mysql","tag-data-types"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-Sd","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/3361","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/comments?post=3361"}],"version-history":[{"count":15,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/3361\/revisions"}],"predecessor-version":[{"id":3665,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/3361\/revisions\/3665"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=3361"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=3361"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=3361"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Storage<\/h4>\n
Internal representation<\/h4>\n
\n
\n
DATETIME<\/code>: Eight bytes:\n\n
YYYY<\/code>\u00d710000 + MM<\/code>\u00d7100 + DD<\/code><\/li>\nHH<\/code>\u00d710000 + MM<\/code>\u00d7100 + SS<\/code><\/li>\n<\/ul>\n<\/div>\n<\/li>\n<\/ul>\n<\/blockquote>\n\n
root@mysql-5.1.51> SELECT NOW()+0;\r\n+-----------------------+\r\n| NOW()+0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 |\r\n+-----------------------+\r\n| 20110307095238.000000 |\r\n+-----------------------+\r\n<\/pre>\n<\/blockquote>\n
Peculiarities<\/h4>\n
My thoughts?<\/h4>\n