Devrais-je utiliser le type de données datetime ou timestamp dans MySQL?
Les horodatages dans MySQL sont généralement utilisés pour suivre les modifications apportées aux enregistrements et sont souvent mis à jour chaque fois que l'enregistrement est modifié. Si vous souhaitez stocker une valeur spécifique, vous devez utiliser un champ datetime.
Si vous vouliez choisir d'utiliser un horodatage UNIX ou un champ natif de date/heure MySQL, choisissez le format natif. Vous pouvez effectuer des calculs dans MySQL de cette façon ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)") et il est simple de changer le format de la valeur en timestamp UNIX ("SELECT UNIX_TIMESTAMP(my_datetime)") lorsque vous interrogez l’enregistrement si vous souhaitez l’utiliser avec PHP.
Dans MySQL 5 et les versions ultérieures, les valeurs TIMESTAMP sont converties du fuseau horaire actuel en UTC pour le stockage, puis reconverties de UTC au fuseau horaire actuel pour être récupérées. (Cela se produit uniquement pour le type de données TIMESTAMP et non pour d'autres types tels que DATETIME.)
Par défaut, le fuseau horaire actuel de chaque connexion est l'heure du serveur. Le fuseau horaire peut être défini connexion par connexion, comme décrit dans la section Prise en charge du fuseau horaire du serveur MySQL.
J'utilise toujours les champs DATETIME pour autre chose que les métadonnées de ligne (date de création ou modification).
Comme mentionné dans la documentation MySQL:
Le type DATETIME est utilisé lorsque vous avez besoin de valeurs contenant à la fois des informations de date et d’heure. MySQL récupère et affiche les valeurs DATETIME au format 'AAAA-MM-JJ HH: MM: SS'. La plage prise en charge est «1000-01-01 00:00:00» à «9999-12-31 23:59:59».
...
Le type de données TIMESTAMP est compris entre '1970-01-01 00:00:01' UTC et '2038-01-09 03:14:07' UTC. Ses propriétés varient en fonction de la version de MySQL et du mode SQL dans lequel le serveur est exécuté.
Il est fort probable que vous atteigniez la limite inférieure des TIMESTAMP généralement utilisés - par exemple. stocker la date de naissance.
Les exemples ci-dessous montrent comment le type de date TIMESTAMP a modifié les valeurs après avoir modifié le time-zone to 'america/new_york' où DATETIME est inchangé.
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 |
+---------------------+---------------------+
J'ai converti ma réponse en article pour que plus de gens puissent trouver cela utile, MySQL: types de données Date/heure/horodatage.
La principale différence est que DATETIME est constant, alors que TIMESTAMP est affecté par le paramètre time_zone.
Il est donc important que vous ayez (ou pourriez avoir à l'avenir) des clusters synchronisés sur plusieurs fuseaux horaires.
En termes plus simples: Si j’ai une base de données en Australie et que je fais un dump de cette base pour synchroniser/remplir une base de données en Amérique, TIMESTAMP se mettrait à jour pour refléter le temps réel de l’événement dans le nouveau fuseau horaire, tandis que DATETIME refléterait toujours l'heure de l'événement dans le fuseau horaire Au .
Un bon exemple d'utilisation de DATETIME dans lequel TIMESTAMP aurait dû être utilisé est Facebook, où leurs serveurs ne sont jamais tout à fait sûr du temps passé dans différents fuseaux horaires. Une fois, j’ai eu une conversation durant laquelle le temps a dit que je répondais aux messages avant que le message ne soit réellement envoyé. (Ceci, bien sûr, aurait également pu être causé par une traduction incorrecte du fuseau horaire dans le logiciel de messagerie si les heures avaient été affichées plutôt que synchronisées.)
Je prends cette décision sur une base sémantique.
J'utilise un horodatage lorsque je dois enregistrer un moment (plus ou moins) fixe. Par exemple, lorsqu'un enregistrement a été inséré dans la base de données ou qu'une action de l'utilisateur a eu lieu.
J'utilise un champ date/heure lorsque la date/heure peut être définie et modifiée arbitrairement. Par exemple, lorsqu'un utilisateur peut enregistrer des rendez-vous modifiés ultérieurement.
TIMESTAMP est 4 octets contre 8 octets pour DATETIME.
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html
Mais comme Scronide l’a dit, sa limite inférieure est de 1970. C’est génial pour tout ce qui pourrait arriver dans le futur;)
TIMESTAMP est quatre octets vs huit octets pour DATETIME.
Les horodatages sont également plus légers sur la base de données et indexés plus rapidement.
Le type DATETIME est utilisé lorsque vous avez besoin de valeurs contenant à la fois des informations de date et d’heure. MySQL récupère et affiche les valeurs DATETIME au format ‘AAAA-MM-JJ HH: MM: SS’. La plage prise en charge est comprise entre 1000-01-01 00:00:00 et 9999-12-31 23:59:59.
Le type de données TIMESTAMP est compris entre 1970-01-01 00:00:01 ‘UTC et 2038-01-09 03:14:07 ′ UTC. Ses propriétés varient en fonction de la version de MySQL et du mode SQL dans lequel le serveur est exécuté.
- DATETIME est constant tandis que TIMESTAMP est affecté par le paramètre time_zone.
Je recommande d'utiliser ni un champ DATETIME ou TIMESTAMP. Si vous voulez représenter un jour spécifique dans son ensemble (comme un anniversaire), utilisez un type DATE, mais si vous êtes plus précis que cela, vous êtes probablement intéressé par l'enregistrement d'un moment réel par opposition à une unité de heure (jour, semaine, mois, année). Au lieu d'utiliser DATETIME ou TIMESTAMP, utilisez un BIGINT et enregistrez simplement le nombre de millisecondes écoulées depuis Epoch (System.currentTimeMillis () si vous utilisez Java). Cela présente plusieurs avantages:
- Vous évitez le blocage du vendeur. Presque toutes les bases de données prennent en charge les entiers de manière relativement similaire. Supposons que vous souhaitiez passer à une autre base de données. Souhaitez-vous vous inquiéter des différences entre les valeurs DATETIME de MySQL et leur définition par Oracle? Même parmi les différentes versions de MySQL, TIMESTAMPS a un niveau de précision différent. Ce n'est que récemment que MySQL a pris en charge les millisecondes dans les horodatages.
- Aucun problème de fuseau horaire. Il y a eu quelques commentaires perspicaces sur ce qui se passe avec les fuseaux horaires avec les différents types de données. Mais est-ce une connaissance commune et vos collègues vont-ils tous prendre le temps de l'apprendre? En revanche, il est assez difficile de perdre du temps à transformer un BigINT en un fichier Java.util.Date. L'utilisation d'un BIGINT entraîne de nombreux problèmes avec les fuseaux horaires.
- Pas de soucis sur les gammes ou la précision. Vous n'avez pas à vous soucier de ce qui sera raccourci par les plages de dates futures (TIMESTAMP ne va que jusqu'en 2038).
- Intégration d'outils tiers. En utilisant un entier, il est facile pour les outils tiers (par exemple, EclipseLink) d’interfacer avec la base de données. Tous les outils tiers ne comprendront pas la même "date et l'heure" que MySQL. Voulez-vous essayer de savoir dans Hibernate si vous devez utiliser un objet Java.sql.TimeStamp ou Java.util.Date si vous utilisez ces types de données personnalisés? L'utilisation de vos types de données de base facilite l'utilisation d'outils tiers.
Ce problème est étroitement lié à la manière dont vous devriez stocker une valeur monétaire (1,99 $) dans une base de données. Devez-vous utiliser un nombre décimal, ou le type Money de la base de données, ou pire un double? Ces trois options sont terribles, pour bon nombre des raisons énumérées ci-dessus. La solution consiste à stocker la valeur de l'argent en cents à l'aide de BIGINT, puis à convertir les cents en dollars lorsque vous affichez la valeur à l'utilisateur. Le travail de la base de données consiste à stocker des données et non à interpréter ces données. Tous ces types de données sophistiqués que vous voyez dans les bases de données (en particulier Oracle) n’ajoutent que peu, et vous permettent de vous immiscer dans l’immobilisation du fournisseur.
Dépend de l'application, vraiment.
Envisagez de définir un horodatage par un utilisateur sur un serveur à New York, pour un rendez-vous à Sanghai. Désormais, lorsque l'utilisateur se connecte à Sanghai, il accède au même horodatage à partir d'un serveur mis en miroir à Tokyo. Il verra le rendez-vous à l'heure de Tokyo décalé par rapport à l'heure de New York.
Donc, pour les valeurs qui représentent l'heure de l'utilisateur, comme un rendez-vous ou une planification, datetime est préférable. Il permet à l'utilisateur de contrôler la date et l'heure exactes souhaitées, quels que soient les paramètres du serveur. L'heure définie est l'heure définie, non affectée par le fuseau horaire du serveur, le fuseau horaire de l'utilisateur ou les modifications apportées au mode de calcul de l'heure d'été (oui, cela change).
Par contre, pour les valeurs qui représentent l’heure du système, telles que les transactions de paiement, les modifications de table ou la journalisation, utilisez toujours des horodatages. Le système ne sera pas affecté par le déplacement du serveur vers un autre fuseau horaire ou par la comparaison entre des serveurs situés dans des fuseaux horaires différents.
Les horodatages sont également plus légers sur la base de données et indexés plus rapidement.
2016 +: Je vous conseille de régler votre fuseau horaire Mysql sur UTC et d'utiliser DATETIME:
Tout framework frontal récent (Angular 1/2, react, Vue, ...) peut facilement et automatiquement convertir votre date/heure UTC en heure locale.
Aditionellement:
- DATETIME peut maintenant être automatiquement défini sur la valeur d'heure actuelle Comment définir une valeur par défaut pour une colonne MySQL Datetime?
- Contrairement à ce qu'on pourrait penser, DATETIME est PLUS RAPIDE THAN TIMESTAMP, http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp- vs-int-performance-and-benchmarking-with-myisam/
- TIMESTAMP est toujours limité à 1970-2038
(Sauf si vous êtes susceptible de changer le fuseau horaire de vos serveurs)
Exemple avec 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' }}
Tous les formats d’heure localisés sont disponibles ici: https://docs.angularjs.org/api/ng/filter/date
Un champ timestamp est un cas particulier du champ datetime. Vous pouvez créer des colonnes timestamp pour avoir des propriétés spéciales. il peut être configuré pour se mettre à jour lui-même lors de la création et/ou de la mise à jour.
En termes "plus grands" de base de données, timestamp a quelques déclencheurs de cas spéciaux.
La bonne dépend de ce que vous voulez faire.
TIMESTAMP est toujours en UTC (c'est-à-dire secondes écoulées depuis le 01/01/1970) et votre serveur MySQL le convertit automatiquement en date/heure pour le fuseau horaire du serveur. TIMESTAMP est la solution à long terme, car vous savez que vos données temporelles seront toujours en UTC. Par exemple, vous ne foirez pas vos dates si vous migrez vers un autre serveur ou si vous modifiez les paramètres de fuseau horaire sur votre serveur.
Comparaison entre DATETIME, TIMESTAMP et DATE
Qu'est-ce que c'est [.fraction]?
- Une valeur DATETIME ou TIMESTAMP peut inclure une fraction de fraction Secondes de fin dans une précision allant jusqu'à microsecondes (6 chiffres). En particulier, toute partie décimale d'une valeur insérée dans une colonne DATETIME .__ ou TIMESTAMP est stockée au lieu d'être ignorée. Ceci est bien sûr optionnel.
Sources:
Il est intéressant de noter que dans MySQL, vous pouvez utiliser quelque chose du type suivant pour créer les colonnes de votre tableau:
on update CURRENT_TIMESTAMP
Cela mettra à jour l'heure à chaque fois que vous modifiez une ligne et est parfois très utile pour les dernières informations stockées stockées. Cela ne fonctionne qu'avec l'horodatage, pas avec datetime.
J'utiliserais toujours un timestamp Unix lorsque je travaillais avec MySQL et PHP. La raison principale en est que la méthode date par défaut dans PHP utilise un horodatage en tant que paramètre, de sorte qu'aucune analyse syntaxique n'est nécessaire.
Pour obtenir le timestamp Unix actuel en PHP, il suffit de faire time();
et dans MySQL, SELECT UNIX_TIMESTAMP();.
D'après mes expériences, si vous voulez un champ de date dans lequel l'insertion ne se produit qu'une seule fois et que vous ne voulez aucune mise à jour ni aucune action sur ce champ particulier, utilisez date time.
Par exemple, considérons une table user avec un champ REGISTRATION DATE. Dans cette table user, si vous souhaitez connaître la dernière heure de connexion d'un utilisateur particulier, utilisez un champ de type timestamp pour qu'il soit mis à jour.
Si vous créez la table à partir de phpMyAdmin , le paramètre par défaut met à jour le champ timestamp lors de la mise à jour d'une ligne. Si votre horodatage ne se met pas à jour avec la mise à jour de la ligne, vous pouvez utiliser la requête suivante pour mettre à jour automatiquement un champ timestamp.
ALTER TABLE your_table
MODIFY COLUMN ts_activity TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;
Le type de données d'horodatage stocke la date et l'heure, mais au format UTC et non au format de fuseau horaire actuel, contrairement à datetime. Et lorsque vous récupérez des données, l'horodatage les convertit à nouveau dans le fuseau horaire actuel.
Supposons donc que vous êtes aux États-Unis et que vous obtenez les données d’un serveur dont le fuseau horaire est celui des États-Unis. Ensuite, vous obtiendrez la date et l'heure en fonction du fuseau horaire des États-Unis. La colonne de type de données d'horodatage est toujours automatiquement mise à jour lorsque sa ligne est mise à jour. Il peut donc être utile de savoir quand une ligne particulière a été mise à jour la dernière fois.
Pour plus de détails, vous pouvez lire le billet de blog Timestamp Vs Datetime.
Référence extraite de cet article:
Les principales différences:
TIMESTAMP utilisé pour suivre les modifications apportées aux enregistrements et mis à jour chaque fois que l'enregistrement est modifié . DATETIME utilisé pour stocker une valeur spécifique et statique non affectée par les modifications apportées aux enregistrements.
TIMESTAMP est également affecté par différents réglages liés à TIME ZONE . DATETIME est constant.
TIMESTAMP a converti en interne le fuseau horaire actuel en UTC pour le stockage et, lors de la récupération, est reconverti dans le fuseau horaire actuel . DATETIME ne peut pas le faire.
Plage prise en charge par TIMESTAMP: '1970-01-01 00:00:01 UTC à' 2038-01-19 03:14:07 ′ UTC DATETIME plage prise en charge: '1000-01-01 00:00:00 à '9999-12-31 23:59:59'
Méfiez-vous des changements d'horodatage lorsque vous effectuez une instruction UPDATE sur une table. Si vous avez une table avec les colonnes 'Nom' (varchar), 'Age' (int) et 'Date_Added' (horodatage) et que vous exécutez l'instruction DML suivante
UPDATE table
SET age = 30
chaque valeur de votre colonne "Date_Added" sera alors remplacée par l'horodatage actuel.
J'utilise toujours un horodatage Unix, simplement pour préserver la santé mentale lors de la manipulation de nombreuses informations de date/heure, en particulier lors de l'ajustement des fuseaux horaires, de l'ajout/soustraction de dates, etc. Lorsque vous comparez des horodatages, cela exclut les facteurs de complication du fuseau horaire et vous permet d'économiser des ressources dans votre traitement côté serveur (qu'il s'agisse de requêtes de code d'application ou de base de données), dans la mesure où vous utilisez une arithmétique légère plutôt qu'un ajout/soustraction de date/heure plus lourd. les fonctions.
Une autre chose à considérer:
Si vous construisez une application, vous ne savez jamais comment vos données pourraient être utilisées ultérieurement. Si, par exemple, vous devez comparer un ensemble d'enregistrements de votre ensemble de données avec, par exemple, un ensemble d'éléments provenant d'une API tierce, et leur dire de les classer dans un ordre chronologique, vous serez heureux d'avoir Timestamps Unix pour vos lignes. Même si vous décidez d'utiliser les horodatages MySQL, stockez un horodatage Unix comme assurance.
Dans mon cas, j'ai défini l'heure UTC comme fuseau horaire pour tout: le système, le serveur de base de données, etc. chaque fois que je le peux. Si mon client a besoin d'un autre fuseau horaire, je le configure sur l'application.
Je préfère presque toujours les horodatages aux champs datetime, car les horodatages incluent implicitement le fuseau horaire. Donc, depuis le moment où l'application sera accédée par des utilisateurs de différents fuseaux horaires et que vous voulez qu'ils voient les dates et les heures dans leur fuseau horaire local, ce type de champ est assez facile à utiliser que si les données étaient enregistrées dans des champs de date/heure .
En plus, dans le cas d'une migration de la base de données vers un système avec un autre fuseau horaire, je me sentirais plus à l'aise avec l'utilisation des horodatages. Pour ne pas dire les problèmes possibles lors du calcul des différences entre deux moments avec un changement d'heure d'été entre et une précision d'une heure ou moins.
Donc, pour résumer, j'apprécie les avantages de l'horodatage:
- prêt à être utilisé sur des applications internationales (multi-fuseaux horaires)
- migrations faciles entre les fuseaux horaires
- assez facile à calculer les différences (il suffit de soustraire les deux horodatages)
- pas d'inquiétude à propos des dates d'entrée et de sortie pendant la période estivale
Pour toutes ces raisons, j'ai choisi les champs UTC et Horodatage, le cas échéant. Et j'évite les maux de tête;)
La capacité de TIMESTAMP à se mettre à jour automatiquement en fonction de l'heure actuelle sans utiliser de déclencheurs inutiles m'a paru d'une utilité inégalée. C’est juste moi cependant, bien que TIMESTAMP soit au format UTC, comme il a été dit.
Il peut garder une trace sur différents fuseaux horaires. Par conséquent, si vous devez afficher une heure relative, par exemple, l’heure UTC est celle que vous souhaiteriez.
Une autre différence entre Timestamp et Datetime réside dans Timestamp. La valeur par défaut ne peut pas être NULL.
La différence majeure est
- un INDEX sur date/heure - ne fonctionne pas
- regardez cet article pour voir les problèmes avec l'indexation Datetime - /
look at this post to see problems with Datetime indexing
Je préfère utiliser l'horodatage afin de tout conserver dans un format brut commun et de formater les données dans le code PHP ou dans votre requête SQL. Dans certains cas, il est utile dans votre code de tout conserver en quelques secondes.
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
| 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. |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
J'aime les horodatages Unix, car vous pouvez convertir en chiffres et vous soucier de ces chiffres. De plus, vous ajoutez/soustrayez et obtenez des durées, etc. Puis convertissez le résultat en Date dans le format que vous souhaitez. Ce code recherche le temps en minutes entre un horodatage d'un document et l'heure actuelle.
$date = $item['pubdate']; (etc ...)
$unix_now = time();
$result = strtotime($date, $unix_now);
$unix_diff_min = (($unix_now - $result) / 60);
$min = round($unix_diff_min);
Une TIMESTAMP nécessite 4 octets, alors qu'une DATETIME nécessite 8 octets.
J'utilise simplement la valeur BIGINT non signée lors de l'enregistrement de l'UTC ...
qui peut alors encore être ajusté à l'heure locale en PHP.
la DATETIME à sélectionner avec FROM_UNIXTIME( integer_timestamp_column ).
il faudrait évidemment placer un index sur cette colonne, sinon il n'y aurait pas d'avance.
Non mentionné jusqu'à présent, DEFAULT CURRENT_TIMESTAMP fonctionne uniquement avec l'horodatage mais pas avec les champs de type DateTime.
Cela devient pertinent pour les tables MS Access qui peuvent uniquement utiliser DateTime mais pas Timestamp.
TIMESTAMP est utile lorsque vous avez des visiteurs de différents pays avec des fuseaux horaires différents. vous pouvez facilement convertir TIMESTAMP en n’importe quel fuseau horaire de pays
Beaucoup de réponses suggèrent ici de stocker comme horodatage le cas où vous devez représenter des moments bien définis. Mais vous pouvez également avoir des dates dans le temps datetime si vous les stockez tous au format UTC par convention.
Si vous souhaitez GARANTIR que votre application ne fonctionnera PAS en février 2038, utilisez TIMESTAMP. Référez-vous à votre REFMAN pour la GAMME de dates prises en charge.
J'ai arrêté d'utiliser datetime dans mes applications après avoir fait face à de nombreux problèmes et bugs liés aux fuseaux horaires. IMHO utiliser timestamp est meilleur que datetime dans la plupart des cas.
Quand vous demandez quelle heure est-il? et la réponse est quelque chose comme '2019-02-05 21:18:30', qui n'est pas terminée, pas de réponse définie car il manque une autre partie, dans quel fuseau horaire? Washington? Moscou? Pékin?
L'utilisation de dates/heures sans le fuseau horaire signifie que votre application ne gère qu'un fuseau horaire. Toutefois, les horodatages vous offrent les avantages de datetime et la possibilité d'afficher le même point de temps exact dans des fuseaux horaires différents.
Voici quelques cas qui vous feront regretter d'utiliser datetime et souhaiter que vous stockiez vos données dans des horodatages.
Pour que vos clients se sentent à l'aise, vous voulez leur montrer les heures en fonction de leur fuseau horaire préféré sans leur demander de faire le calcul et de convertir l'heure en un fuseau horaire qui leur convient. tout ce dont vous avez besoin est de changer le fuseau horaire et tout le code de votre application sera le même .(En fait, vous devez toujours définir le fuseau horaire au début de l'application, ou demander le traitement dans le cas d'applications PHP)
SET time_zone = '+2:00';vous avez changé le pays dans lequel vous restez et poursuivez votre travail de maintenance des données tout en les affichant dans un fuseau horaire différent (sans modifier les données réelles).
- vous acceptez les données de différents clients du monde entier, chacun insère l'heure dans son fuseau horaire.
En bref
datetime = application prend en charge 1 fuseau horaire (pour l'insertion et la sélection)
timestamp = application prend en charge tous les fuseaux horaires (pour l'insertion et la sélection)
Cette réponse vise uniquement à mettre en évidence la flexibilité et la facilité des horodatages en ce qui concerne les fuseaux horaires. Elle ne couvre aucune autre différence, comme la taille de la colonne , la plage ou la fraction . _
Différence entre DATETIME et TIMESTAMP
La plage prise en charge pour DATETIME va de "1000-01-01 00:00:00" à "9999-12-31 23:59:59", tandis que pour TIMESTAMP, elle est de "1970-01-01 00:00:01" UTC à '2038-01-09 03:14:07' UTC.
Avant MySQL 5.6.4, TIMESTAMP nécessitait 4 octets (+3 octets pour des fractions de secondes) pour stocker des données, tandis que DATETIME exigeait 8 octets (+3 octets pour des fractions de secondes).
Depuis MySQL 5.6.4, DATETIME nécessite 5 octets + 3 octets supplémentaires pour le stockage des données en une fraction de seconde.
4.Dans MySQL5 +, la valeur TIMESTAMP est convertie de l'heure actuelle en UTC et inversement, tandis que DATETIME n'effectue aucune conversion.
TIMESTAMP diffère selon les paramètres de fuseau horaire actuels, tandis que DATETIME reste constant. Les données TIMESTAMP peuvent être indexées alors que les données DATETIME ne le peuvent pas.
Les requêtes avec DATETIME ne seront pas mises en cache, mais celles avec TIMESTAMP seront mises en cache.
timestamp est l'heure actuelle d'un événement enregistré par un ordinateur via Protocole NTP (Network Time Protocol) .
datetime est un fuseau horaire actuel défini dans votrePHPconfiguration.