MySQL에서 datetime 또는 timestamp 데이터 유형을 사용해야 합니까?

MySQL에서 datetime 또는 timestamp 데이터 유형을 사용해야 합니까?

datetime 필드 또는 timestamp 필드 중 어느 쪽을 사용하는 것이 좋으며, 그 이유(MySQL 사용)는 무엇입니까?

서버측에서 PHP를 사용하고 있습니다.

MySQL의 타임스탬프는 일반적으로 레코드의 변경을 추적하는 데 사용되며 레코드가 변경될 때마다 업데이트됩니다.특정 값을 저장하려면 datetime 필드를 사용해야 합니다.

UNIX 타임스탬프를 사용할지 네이티브 MySQL datetime 필드를 사용할지 여부를 결정하는 경우 네이티브로 진행합니다.DATETIME포맷합니다.이 방법으로 MySQL 내에서 계산을 수행할 수 있습니다.("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)")값의 형식을 UNIX 타임스탬프로 변경하는 것은 간단합니다.("SELECT UNIX_TIMESTAMP(my_datetime)")PHP를 사용하여 레코드를 조작하고 싶은 경우 레코드를 쿼리합니다.

MySQL 5 이상에서는 TIMESTAMP 값이 현재 시간대에서 UTC로 변환되어 저장되며 UTC에서 현재 시간대로 다시 변환되어 검색됩니다.(이는 TIMESTAMP 데이터 타입에만 해당되며 DATETIME 등의 다른 타입에는 적용되지 않습니다).

기본적으로 각 연결에 대한 현재 표준 시간대는 서버의 시간입니다.표준 시간대는 MySQL Server 표준 시간대 지원에 설명된 대로 연결별로 설정할 수 있습니다.

행 메타데이터(작성 또는 수정된 날짜) 이외의 모든 항목에 항상 DATETIME 필드를 사용합니다.

MySQL 매뉴얼에 기재되어 있는 바와 같이

DATETIME 유형은 날짜와 시간 정보를 모두 포함하는 값이 필요할 때 사용됩니다.MySQL은 'YYY-MM-DD HH:MM:SS' 형식입니다.지원되는 범위는 '1000-01-01 00:00:00' ~ '9999-12-31 23:59:59'입니다.

...

TIMESTAMP 데이터 유형의 범위는 '1970-01-01 00:00:01' UTC에서 '2038-01-09 03:14:07' UTC입니다.MySQL 버전 및 서버가 실행 중인 SQL 모드에 따라 속성이 달라집니다.

일반적으로 사용 중인 TIMESTAMP의 하한(생일 저장 등)에 도달할 가능성이 높습니다.

다음 예시는 다음 예시와 같습니다.TIMESTAMPdate type이 변경 후 값을 변경했습니다.time-zone to 'america/new_york'어디에DATETIME변경되지 않습니다.

mysql> show variables like '%time_zone%';
+------------------+---------------------+
| Variable_name    | Value               |
+------------------+---------------------+
| system_time_zone | India Standard Time |
| time_zone        | Asia/Calcutta       |
+------------------+---------------------+

mysql> create table datedemo(
    -> mydatetime datetime,
    -> mytimestamp timestamp
    -> );

mysql> insert into datedemo values ((now()),(now()));

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 14:11:09 |
+---------------------+---------------------+

mysql> set time_zone="america/new_york";

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 04:41:09 |
+---------------------+---------------------+

더 많은 사람들이 유용한 MySQL: Datetime Vs Timestamp Data Types를 찾을 수 있도록 내 답변을 문서로 변환했습니다.

주요 차이점은 DATETIME은 일정하고 TIMESTAMP는 TIMESTAMP의 영향을 받는다는 것입니다.time_zone설정.

따라서 이는 시간대에 걸쳐 동기화된 클러스터가 있거나 앞으로 동기화된 경우에만 문제가 됩니다.

간단히 말하면, 내가 호주에서 데이터베이스를 가지고 있고, 미국에서 데이터베이스를 동기화/입력하기 위해 그 데이터베이스를 덤프하면, TIMESTAMP는 새로운 타임존에서 이벤트의 실시간을 반영하도록 갱신되지만, DATETIME은 여전히 au 타임존에서 이벤트의 시간을 반영합니다.

TIMESTAMP를 사용했어야 할 DATETIME이 사용되고 있는 좋은 예는 Facebook입니다.이 Facebook에서는 서버는 타임존 전체에서 몇 시에 어떤 일이 일어났는지 전혀 알 수 없습니다.한번은, 실제로 메세지가 송신되기 전에, 메세지에 답신하고 있다고 하는 시간을 이야기하고 있었습니다(이것은, 물론, 시각이 동기하지 않고 투고되고 있는 경우는, 메세지 소프트웨어의 타임 존 번역이 잘못되어 있었을 가능성도 있습니다).

나는 의미론적 관점에서 이 결정을 내린다.

타임스탬프는 고정 시점(다소)을 기록해야 할 때 사용합니다.예를 들어 레코드가 데이터베이스에 삽입된 경우 또는 일부 사용자 작업이 수행된 경우입니다.

날짜/시간을 임의로 설정 및 변경할 수 있는 경우 datetime 필드를 사용합니다.예를 들어 사용자가 나중에 변경 약속을 저장할 수 있는 경우입니다.

DATETIME 필드도 TIMESTAMP 필드도 사용하지 않는 것이 좋습니다.특정 날짜 전체를 (생일처럼) 나타내려면 DATE 유형을 사용합니다. 그러나 더 구체적으로 말하면 시간 단위(일, 주, 월, 년)가 아닌 실제 순간을 기록하는 것이 좋습니다.DATETIME 또는 TIMESTAMP를 사용하는 대신 BIGINT를 사용하여 에폭(Java를 사용하는 경우 System.currentTimeMillis()) 이후의 밀리초 수를 저장합니다.여기에는 몇 가지 장점이 있습니다.

1. 벤더의 구속을 피할 수 있습니다.거의 모든 데이터베이스가 비교적 유사한 방식으로 정수를 지원합니다.다른 데이터베이스로 이동한다고 가정합니다.MySQL의 DATETIME 값과 Oracle의 정의 방법 간의 차이를 걱정하시겠습니까?MySQL의 다른 버전에서도 TIMESTAMPS의 정밀도는 다릅니다.MySQL이 타임스탬프에서 밀리초를 지원하게 된 것은 최근의 일입니다.
2. 시간대 문제는 없습니다.데이터 타입이 다른 타임존에서는 어떤 일이 일어나는지에 대한 통찰력 있는 코멘트가 있었습니다.하지만 이것이 상식이고, 당신의 동료들은 모두 시간을 들여 배울까요?반면에 빅을 바꾸는 것은 꽤 어렵다.java.util에 INT를 입력합니다.날짜. BIGINT를 사용하면 타임존에 문제가 많이 발생합니다.
3. 범위나 정밀도에 대한 걱정은 없습니다.미래의 날짜 범위로 단축되는 것은 걱정할 필요가 없습니다(TIMESTamp는 2038년만).
4. 서드파티제 도구 통합.정수를 사용하면 서드파티 도구(예: EclipseLink)가 데이터베이스와 인터페이스하는 것이 간단해집니다.모든 서드파티 툴이 MySQL과 같은 "datetime"을 이해하는 것은 아닙니다.hibernate에서 java.sql을 사용해야 하는지 알아보려고 합니다.타임스탬프 또는 java.util.이러한 사용자 지정 데이터 유형을 사용하는 경우 날짜 개체?기본 데이터 유형을 사용하면 타사 도구를 쉽게 사용할 수 있습니다.

이 문제는 화폐 가치(1.99달러)를 데이터베이스에 저장하는 방법과 밀접하게 관련되어 있습니다.10진수, 데이터베이스의 Money 유형 또는 최악의 Double 중 어느 쪽을 사용해야 합니까?위의 3가지 옵션 모두 동일한 이유로 인해 문제가 발생합니다.해결책은 BIGINT를 사용하여 돈의 가치를 센트로 저장한 후 사용자에게 값을 표시할 때 센트를 달러로 변환하는 것입니다.데이터베이스의 역할은 데이터를 저장하는 것이지 데이터를 저장하는 것이 아닙니다.데이터베이스(특히 Oracle)에서 볼 수 있는 이러한 고급 데이터 유형은 거의 추가되지 않으며 공급업체에 종속되어 있습니다.

1. TIMESTAMP4바이트가 8바이트가 아닌DATETIME.

2. 또한 타임스탬프는 데이터베이스에서 더 가볍고 더 빠르게 인덱싱됩니다.

3. 그DATETIMEtype은 날짜와 시간 정보를 모두 포함하는 값이 필요할 때 사용합니다.MySQL 검색 및 표시DATETIME에 있어서의 가치관YYYY-MM-DD HH:MM:SS포맷합니다.지원되는 범위는 다음과 같습니다.1000-01-01 00:00:00로.9999-12-31 23:59:59.그TIMESTAMP데이터 타입의 범위는1970-01-01 00:00:01 UTC로.2038-01-09 03:14:07 UTCMySQL 버전 및 서버가 실행 중인 SQL 모드에 따라 속성이 달라집니다.

4. DATETIME단,TIMESTAMP의 영향을 받습니다.time_zone설정.

타임스탬프는 4바이트인데 반해 DATETIME은 8바이트입니다.

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

하지만 스크로나이드는 1970년의 하한선을 가지고 있다고 말했다.장래에 일어날지도 모르는 모든 일에 있어서, 이것은 매우 좋은 일입니다.

응용 프로그램에 따라 다르죠.

사용자가 Sanghai에서 약속을 위해 뉴욕에 있는 서버에 타임스탬프를 설정하는 것을 고려해 보십시오.사용자가 상하이에서 접속하면 도쿄의 미러 서버에서 동일한 약속 타임 스탬프에 액세스합니다.그는 원래의 뉴욕 시간과는 다른 도쿄 시간으로 약속을 볼 것이다.

따라서 약속이나 일정과 같이 사용자 시간을 나타내는 값에는 날짜/시간이 더 좋습니다.서버 설정에 관계없이 사용자가 원하는 정확한 날짜와 시간을 제어할 수 있습니다.설정된 시간은 설정된 시간으로 서버의 시간대, 사용자의 시간대 또는 서머타임이 계산되는 방법의 변경에 영향을 받지 않습니다(예, 변경됩니다).

한편, 지불 트랜잭션, 테이블 수정 또는 로깅과 같이 시스템 시간을 나타내는 값에는 항상 타임스탬프를 사용하십시오.서버를 다른 타임존으로 이동하거나 다른 타임존의 서버를 비교해도 시스템은 영향을 받지 않습니다.

또한 타임스탬프는 데이터베이스에서 더 가볍고 더 빠르게 인덱싱됩니다.

2016 +: Mysql 시간대를 UTC로 설정하고 DATETIME을 사용하는 것이 좋습니다.

최신 프런트 엔드 프레임워크(Angular 1/2, react, Vue 등)를 사용하면 UTC 날짜 시간을 로컬 시간으로 쉽고 자동으로 변환할 수 있습니다.

기타:

• DATETIME을 현재 시간 값으로 자동 설정할 수 있습니다. MySQL Datetime 열의 기본값을 설정하려면 어떻게 해야 합니까?
• 생각과는 달리 DATETIME이 타임스탬프보다 빠릅니다.http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with-myisam/
• TIMESTAMP는 아직 1970-2038로 제한됩니다.

(서버의 타임존을 변경할 가능성이 없는 한)

---

AngularJs를 사용한 예

// back-end: format for angular within the sql query
SELECT DATE_FORMAT(my_datetime, "%Y-%m-%dT%TZ")...

// font-end Output the localised time
{{item.my_datetime | date :'medium' }}

현지화된 모든 시간 형식은 https://docs.angularjs.org/api/ng/filter/date에서 확인할 수 있습니다.

둘 다 아니다.일반적인 사용 예에서는 및 유형이 기본적으로 구분되어 있습니다.MySQL은 향후 이러한 기능을 변경할 예정입니다.를 사용해 주세요.BIGINT및 UNIX 타임스탬프를 참조해 주세요.단, 특별한 이유가 있는 경우는 제외합니다.

특수한 경우

다음은 선택하기 쉽고 이 답변에 분석 및 일반적인 권장 사항이 필요하지 않은 몇 가지 구체적인 상황입니다.

• 날짜만 - 날짜만 신경쓰고(다음 음력 설날 날짜, 2022-02-01) 해당 날짜가 적용되는 시간대를 명확하게 이해한 경우(또는 음력 설날과 같이 상관 없음)에는 열 유형을 사용하십시오.

• 삽입 시간 기록 - 데이터베이스에 행 삽입 날짜/시간을 기록하고 있으며, 향후 17년 이내에 응용 프로그램이 고장나도 상관하지 않는 경우 다음 명령을 사용하십시오.TIMESTAMP디폴트값으로CURRENT_TIMESTAMP().

왜?TIMESTAMP고장났나?

그TIMESTAMPtype은 UTC 시간대로 디스크에 저장됩니다.즉, 물리적으로 서버를 이동해도 서버가 파손되지 않습니다.✅씨네요.그러나 현재 정의된 타임스탬프는 2038 ❌ 해에 완전히 작동을 중지합니다.

매번 너는INSERT INTO또는SELECT FROM a TIMESTAMP컬럼에는 클라이언트/어플리케이션서버의 물리적인 장소(타임존 설정 등)가 고려됩니다.애플리케이션 서버를 이동하면 ❌ 날짜가 만료됩니다.

(업데이트 2022-04-29 MySQL에서 8.0.28로 수정되었지만 운영 환경이 Cent에 있는 경우)OS 7 또는 그 외의 많은 타입의 이행 패스는, 이 서포트를 받을 때까지 오랜 시간이 걸립니다).

왜?VARCHAR고장났나?

그VARCHARtype을 사용하면 로컬이 아닌 날짜/시간/둘 다 ISO 8601 형식으로 명확하게 저장할 수 있으며 2037년 이후의 날짜에도 사용할 수 있습니다.줄루 시간을 사용하는 것이 일반적이지만 ISO 8601에서는 모든 오프셋을 인코딩할 수 있습니다.MySQL 날짜 및 시간 함수는 원하는 날짜/시간/둘 다 입력으로 문자열을 지원하지만, 입력이 시간대 오프셋을 사용하는 경우 결과가 올바르지 않기 때문에 이 기능은 덜 유용합니다.

또한.VARCHAR는 여분의 바이트의 스토리지를 사용합니다.

왜?DATETIME고장났나?

A DATETIME저장하다DATE및 aTIME같은 열에 있습니다.표준 시간대를 이해하지 못하고 표준 시간대가 ❌ 어디에도 저장되지 않는 한 이 두 가지 모두 의미가 없습니다.타임존은 데이터에 밀접하게 연결되어 있기 때문에 컬럼에 원하는 타임존을 코멘트로 입력해야 합니다.칼럼 코멘트를 사용하는 사람은 거의 없기 때문에, 이것은 실수입니다.애리조나에서 서버를 상속받았기 때문에 항상 모든 타임스탬프를 애리조나 시간으로 변환한 다음 다른 시간으로 변환해야 합니다.

(업데이트 2021-12-08 수년간 가동한 후 서버를 재부팅하여 데이터베이스 클라이언트(업그레이드 포함)가 UTC로 리셋되었습니다.즉, 어플리케이션에서는 리셋 전과 리셋 후의 날짜를 다르게 처리해야 합니다.하드코드!)

유일한 상황 aDATETIME정답은 다음 문장을 완성하는 것입니다.

여러분의 2020년 새해는 정확히 5시에 시작됩니다.DATETIME("2020-01-01 00:00:00").

다른 좋은 용도는 없다DATETIMEs. 델라웨어 시 정부용 웹 서버를 상상해 보십시오.이 서버 및 이 서버에 접속하는 모든 사용자의 타임존은 동부 타임존이 있는 델라웨어에 있음을 암시할 수 있습니다.틀렸습니다! 이 밀레니엄 시대에 우리는 서버를 "클라우드"에 존재하는 것으로 생각합니다.따라서 서버를 특정 시간대로 생각하는 것은 항상 잘못된 것입니다.서버는 언젠가 이동될 것이기 때문입니다.

주의: MySQL은 현재 표준 시간대 오프셋을 지원하고 있습니다.DATETIME리터럴(@Marko 감사합니다).이렇게 하면 삽입이 될 수 있습니다.DATETIME이 치명적인 문제는 위의 ("❌")를 식별하지만 데이터의 불완전하고 쓸모없는 데이터의 의미를 해결하지 않습니다.

사용방법BIGINT?

정의:

CREATE TEMPORARY TABLE good_times (
    a_time BIGINT
)

특정 값 삽입:

INSERT INTO good_times VALUES (
    UNIX_TIMESTAMP(CONVERT_TZ("2014-12-03 12:24:54", '+00:00', @@global.time_zone))
);

또는 물론 다음과 같은 어플리케이션에서 훨씬 더 나은 결과를 얻을 수 있습니다.

$statement = $myDB->prepare('INSERT INTO good_times VALUES (?)');
$statement->execute([$someTime->getTimestamp()]);

선택:

SELECT a_time FROM good_times;

상대시간 필터링(과거 30일 이내 게시물 선택, 등록 후 10분 이내 구매 사용자 검색) 기법도 있습니다.

TIMESTAMP는 항상 UTC(즉, 1970-01-01 이후 경과한 초수)이며 MySQL 서버는 이를 연결 시간대의 날짜/시간으로 자동 변환합니다.장기적으로는 TIMESTAMP가 최적의 방법입니다.시간 데이터는 항상 UTC에 있기 때문입니다.예를 들어, 다른 서버로 마이그레이션하거나 서버의 시간대 설정을 변경해도 날짜를 망치지 않습니다.

주의: 기본 접속 타임존은 서버 타임존이지만 세션별로 변경할 수 있습니다( 참조).SET time_zone = ...).

A timestamp필드는 의 특수한 경우입니다.datetime이 필드를 생성할 수 있습니다.timestamp컬럼은 특별한 속성을 가집니다.생성 및/또는 업데이트 시 자동으로 업데이트되도록 설정할 수 있습니다.

'더 큰' 데이터베이스 용어로는timestamp특별한 경우 트리거가 몇 개 있어요

What the right one is depends entirely on what you want to do.

Comparison between DATETIME, TIMESTAMP and DATE

What is that [.fraction]?

• A DATETIME or TIMESTAMP value can include a trailing fractional seconds part in up to microseconds (6 digits) precision. In particular, any fractional part in a value inserted into a DATETIME or TIMESTAMP column is stored rather than discarded. This is of course optional.

Sources:

• MySQL Date/Time data types reference
• MySQL Storage Requirements reference

It is worth noting in MySQL you can use something along the lines of the below when creating your table columns:

on update CURRENT_TIMESTAMP

This will update the time at each instance you modify a row and is sometimes very helpful for stored last edit information. This only works with timestamp, not datetime however.

I would always use a Unix timestamp when working with MySQL and PHP. The main reason for this being the default date method in PHP uses a timestamp as the parameter, so there would be no parsing needed.

To get the current Unix timestamp in PHP, just do time();
and in MySQL do SELECT UNIX_TIMESTAMP();.

From my experiences, if you want a date field in which insertion happens only once and you don't want to have any update or any other action on that particular field, go with date time.

For example, consider a user table with a REGISTRATION DATE field. In that user table, if you want to know the last logged in time of a particular user, go with a field of timestamp type so that the field gets updated.

If you are creating the table from phpMyAdmin the default setting will update the timestamp field when a row update happens. If your timestamp filed is not updating with row update, you can use the following query to make a timestamp field get auto updated.

ALTER TABLE your_table
      MODIFY COLUMN ts_activity TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

The timestamp data type stores date and time, but in UTC format, not in the current timezone format as datetime does. And when you fetch data, timestamp again converts that into the current timezone time.

So suppose you are in USA and getting data from a server which has a time zone of USA. Then you will get the date and time according to the USA time zone. The timestamp data type column always get updated automatically when its row gets updated. So it can be useful to track when a particular row was updated last time.

상세한 것에 대하여는, 블로그의 투고 「Timestamp Vs Datetime」을 참조해 주세요.

저는 항상 Unix 타임스탬프를 사용합니다.많은 날짜 정보를 다룰 때, 특히 시간대 조정, 날짜 추가/감축 등을 수행할 때 온전성을 유지하기 위해서입니다.타임스탬프를 비교할 때 타임존의 복잡한 요소는 제외됩니다.또한 서버측 처리(어플리케이션코드인지 데이터베이스 쿼리인지에 관계없이)에 자원을 절약할 수 있습니다.이는 보다 무거운 날짜/시간 추가/감산 함수를 사용하기 위해서입니다.

고려해야 할 또 다른 사항:

애플리케이션을 구축하는 경우 데이터를 어떻게 사용해야 하는지 알 수 없습니다.예를 들어, 데이터 세트의 많은 레코드를 서드파티 API의 많은 항목과 비교하고, 그것들을 시간순으로 정렬해야 한다면, 행에 UNIX 타임스탬프가 있으면 매우 만족할 것입니다.MySQL 타임스탬프를 사용하기로 결정한 경우에도 UNIX 타임스탬프를 보험으로 저장하십시오.

이 문서에서 인용한 참조:

주요 차이점은 다음과 같습니다.

TIMESTAMP 는, 레코드의 변경을 추적해, 레코드가 변경될 때마다 갱신하기 위해서 사용됩니다.DATETIME은 레코드 변경의 영향을 받지 않는 특정 정적 값을 저장하기 위해 사용됩니다.

TIMESTAMP 는, 다른 TIMEZONE 관련 설정에도 영향을 받습니다.DATETIME은 일정합니다.

TIMESTAMP는 내부적으로 저장하기 위해 현재 시간대를 UTC로 변환하고 검색 중에 현재 시간대로 다시 변환합니다.DATETIME은 이 작업을 수행할 수 없습니다.

TIMESTAMP 지원 범위: '1970-01 00:00:01' UTC ~ '2038-01-19 03:14:07' UTC DATETIME 지원 범위: '1000-01-01 00:00:00' ~ '99999-12-31 23:59:59'

제 경우, UTC는 가능한 한 시스템, 데이터베이스 서버 등 모든 것의 표준 시간대로 설정합니다.고객이 다른 표준 시간대를 필요로 하는 경우 앱에서 설정합니다.

타임스탬프에는 시간대가 암묵적으로 포함되어 있기 때문에 거의 항상 datetime 필드보다 타임스탬프를 선호합니다.따라서 다른 시간대 사용자로부터 앱에 액세스하고 로컬 시간대에서 날짜와 시간을 보고 싶은 순간, 이 필드 유형은 데이터를 날짜 필드에 저장했을 때보다 훨씬 쉽게 실행할 수 있습니다.

As a plus, in the case of a migration of the database to a system with another timezone, I would feel more confident using timestamps. Not to say possible issues when calculating differences between two moments with a sumer time change in between and needing a precision of 1 hour or less.

So, to summarize, I value this advantages of timestamp:

• ready to use on international (multi time zone) apps
• easy migrations between time zones
• pretty easy to calculate diferences (just subtract both timestamps)
• no worry about dates in/out a summer time period

For all this reasons, I choose UTC & timestamp fields where posible. And I avoid headaches ;)

Beware of timestamp changing when you do a UPDATE statement on a table. If you have a table with columns 'Name' (varchar), 'Age' (int), and 'Date_Added' (timestamp) and you run the following DML statement

UPDATE table
SET age = 30

then every single value in your 'Date_Added' column would be changed to the current timestamp.

+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
|                                       TIMESTAMP                                       |                                 DATETIME                                 |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
| TIMESTAMP requires 4 bytes.                                                           | DATETIME requires 8 bytes.                                               |
| Timestamp is the number of seconds that have elapsed since January 1, 1970 00:00 UTC. | DATETIME is a text displays 'YYYY-MM-DD HH:MM:SS' format.                |
| TIMESTAMP supported range: ‘1970-01-01 00:00:01′ UTC to ‘2038-01-19 03:14:07′ UTC.    | DATETIME supported range: ‘1000-01-01 00:00:00′ to ‘9999-12-31 23:59:59′ |
| TIMESTAMP during retrieval converted back to the current time zone.                   | DATETIME can not do this.                                                |
| TIMESTAMP is used mostly for metadata i.e. row created/modified and audit purpose.    | DATETIME is used mostly for user-data.                                   |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+

I found unsurpassed usefulness in TIMESTAMP's ability to auto update itself based on the current time without the use of unnecessary triggers. That's just me though, although TIMESTAMP is UTC like it was said.

It can keep track across different timezones, so if you need to display a relative time for instance, UTC time is what you would want.

DATETIME vs TIMESTAMP:

TIMESTAMP used to track changes of records, and update every time when the record is changed.

DATETIME used to store specific and static value which is not affected by any changes in records.

TIMESTAMP also affected by different TIME ZONE related setting. DATETIME is constant.

TIMESTAMP internally converted a current time zone to UTC for storage, and during retrieval convert the back to the current time zone.

DATETIME can not do this.

TIMESTAMP is 4 bytes and DATETIME is 8 bytes.

TIMESTAMP supported range: ‘1970-01-01 00:00:01′ UTC to ‘2038-01-19 03:14:07′ UTC DATETIME supported range: ‘1000-01-01 00:00:00′ to ‘9999-12-31 23:59:59′

The major difference is

• a INDEX's on Timestamp - works
• a INDEX's on Datetime - Does not work

look at this post to see problems with Datetime indexing

I stopped using datetime in my applications after facing many problems and bugs related to time zones. IMHO using timestamp is better than datetime in most of the cases.

When you ask what is the time ? and the answer comes as something like '2019-02-05 21:18:30', that is not completed, not defined answer because it lacks another part, in which timezone ? Washington ? Moscow ? Beijing ?

Using datetimes without the timezone means that your application is dealing with only 1 timezone, however timestamps give you the benefits of datetime plus the flexibility of showing the same exact point of time in different timezones.

Here are some cases that will make you regret using datetime and wish that you stored your data in timestamps.

1. For your clients comfort you want to show them the times based on their preferred time zones without making them doing the math and convert the time to their meaningful timezone. all you need is to change the timezone and all your application code will be the same.(Actually you should always define the timezone at the start of the application, or request processing in case of PHP applications)

   SET time_zone = '+2:00';
   

2. you changed the country you stay in, and continue your work of maintaining the data while seeing it in a different timezone (without changing the actual data).

3. you accept data from different clients around the world, each of them inserts the time in his timezone.

In short

datetime = application supports 1 timezone (for both inserting and selecting)

timestamp = application supports any timezone (for both inserting and selecting)

---

This answer is only for putting some highlight on the flexibility and ease of timestamps when it comes to time zones , it is not covering any other differences like the column size or range or fraction.

Another difference between Timestamp and Datetime is in Timestamp you can't default value to NULL.

I prefer using timestamp so to keep everything in one common raw format and format the data in PHP code or in your SQL query. There are instances where it comes in handy in your code to keep everything in plain seconds.

ReferenceURL : https://stackoverflow.com/questions/409286/should-i-use-the-datetime-or-timestamp-data-type-in-mysql