Dois-je utiliser le type de données datetime ou timestamp dans MySQL?

Recommanderiez-vous d'utiliser un datetime ou un horodatage champ , et pourquoi (en utilisant MySQL)?

Je travaille avec PHP côté serveur.

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 décider entre utiliser un horodatage UNIX ou un champ de date / heure MySQL natif, optez pour 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 horodatage UNIX ("SELECT UNIX_TIMESTAMP(my_datetime)")lorsque vous interrogez l'enregistrement si vous souhaitez l'utiliser avec PHP.

Dans MySQL 5 et versions ultérieures, les valeurs TIMESTAMP sont converties du fuseau horaire actuel en UTC pour le stockage, et reconverties de l'UTC au fuseau horaire actuel pour la récupération. (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 pour chaque connexion est l'heure du serveur. Le fuseau horaire peut être défini pour chaque connexion, comme décrit dans Prise en charge du fuseau horaire du serveur MySQL .

J'utilise toujours les champs DATETIME pour autre chose que des métadonnées de ligne (date de création ou de 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 'YYYY-MM-DD HH: MM: SS'. La plage prise en charge est de '1000-01-01 00:00:00' à '9999-12-31 23:59:59'.

...

Le type de données TIMESTAMP a une plage de '1970-01-01 00:00:01' UTC à '2038-01-09 03:14:07' UTC. Il a des propriétés variables, selon la version de MySQL et le mode SQL dans lequel le serveur s'exécute.

Il est fort probable que vous atteigniez la limite inférieure des TIMESTAMPs en général - par exemple, le stockage de la date de naissance.

Les exemples ci-dessous montrent comment le TIMESTAMPtype de date a changé les valeurs après avoir changé time-zone to 'america/new_york'où DATETIMEest 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 afin que plus de gens puissent trouver cela utile, MySQL: Datetime Versus Timestamp Data Types .

La principale différence est que DATETIME est constant tandis que TIMESTAMP est affecté par le time_zoneparamètre.

Cela n'a donc d'importance que lorsque vous avez - 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 vidage de cette base de données pour synchroniser / remplir une base de données en Amérique, le TIMESTAMP serait mis à jour pour refléter l'heure réelle de l'événement dans le nouveau fuseau horaire, tandis que DATETIME reflètent toujours l'heure de l'événement dans le fuseau horaire de l'UA .

Un excellent exemple d'utilisation de DATETIME là où TIMESTAMP aurait dû être utilisé est sur Facebook, où leurs serveurs ne sont jamais tout à fait sûrs de ce qui s'est passé entre les fuseaux horaires. Une fois, j'ai eu une conversation dans laquelle le temps a dit que je répondais aux messages avant que le message ne soit envoyé. (Bien sûr, cela pourrait également être dû à une mauvaise traduction du fuseau horaire dans le logiciel de messagerie si les heures étaient affichées plutôt que synchronisées.)

Je prends cette décision sur une base sémantique.

J'utilise un horodatage lorsque j'ai besoin d'enregistrer un point fixe (plus ou moins) dans le temps. Par exemple, lorsqu'un enregistrement a été inséré dans la base de données ou lorsqu'une action utilisateur a eu lieu.

J'utilise un champ datetime lorsque la date / heure peut être définie et modifiée arbitrairement. Par exemple, lorsqu'un utilisateur peut enregistrer des rendez-vous de modification ultérieurs.

Je recommande d'utiliser ni un champ DATETIME ou TIMESTAMP. Si vous souhaitez 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é à enregistrer un moment réel par opposition à une unité de heure (jour, semaine, mois, année). Au lieu d'utiliser un DATETIME ou TIMESTAMP, utilisez un BIGINT et stockez simplement le nombre de millisecondes depuis l'époque (System.currentTimeMillis () si vous utilisez Java). Cela présente plusieurs avantages:

1. Vous évitez le blocage des fournisseurs. Presque toutes les bases de données prennent en charge des entiers de manière relativement similaire. Supposons que vous souhaitiez passer à une autre base de données. Voulez-vous vous soucier des différences entre les valeurs DATETIME de MySQL et comment Oracle les définit? Même parmi différentes versions de MySQL, TIMESTAMPS ont un niveau de précision différent. Ce n'est que récemment que MySQL a pris en charge les millisecondes dans les horodatages.
2. 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 prendront-ils tous le temps de l'apprendre? D'un autre côté, il est assez difficile de gâcher la transformation d'un BigINT en java.util.Date. L'utilisation d'un BIGINT provoque la chute de nombreux problèmes avec les fuseaux horaires.
3. Aucun souci de portée ou de précision. Vous n'avez pas à vous soucier de ce qui sera écourté par les futures plages de dates (TIMESTAMP ne va qu'en 2038).
4. Intégration d'outils tiers. En utilisant un entier, il est trivial pour les outils tiers (par exemple EclipseLink) de s'interfacer avec la base de données. Tous les outils tiers n'auront pas la même compréhension d'une «date / heure» que MySQL. Vous voulez essayer de déterminer 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 est facile à utiliser avec des outils tiers.

Ce problème est étroitement lié à la façon dont vous devez stocker une valeur monétaire (c'est-à-dire 1,99 $) dans une base de données. Devez-vous utiliser un Decimal, ou le type Money de la base de données, ou pire encore un Double? Ces 3 options sont terribles, pour plusieurs des mêmes 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) ajoutent peu et vous lancent sur la voie du verrouillage des fournisseurs.

TIMESTAMP est de 4 octets contre 8 octets pour DATETIME.

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

Mais comme le dit scronide, il a une limite inférieure de l'année 1970. C'est bien pour tout ce qui pourrait arriver à l'avenir;)

1. TIMESTAMP est de quatre octets contre huit octets pour DATETIME.

2. Les horodatages sont également plus légers sur la base de données et indexés plus rapidement.

3. 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 'YYYY-MM-DD HH: MM: SS'. La plage prise en charge est de '1000-01-01 00:00:00' à '9999-12-31 23:59:59'.

Le type de données TIMESTAMP a une plage de '1970-01-01 00:00:01' UTC à '2038-01-09 03:14:07' UTC. Il a des propriétés variables, selon la version de MySQL et le mode SQL dans lequel le serveur s'exécute.

4. DATETIME est constant tandis que TIMESTAMP est affecté par le paramètre time_zone.

Cela dépend de l'application, vraiment.

Pensez à 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 de rendez-vous à partir d'un serveur en miroir à Tokyo. Il verra le rendez-vous à l'heure de Tokyo, décalé de l'heure d'origine de New York.

Ainsi, pour les valeurs qui représentent le temps de l'utilisateur comme un rendez-vous ou un horaire, datetime est meilleur. 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 par les changements dans la façon dont l'heure d'été est calculée (oui, elle change).

D'un autre côté, pour les valeurs qui représentent l'heure système comme 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 lors de la comparaison entre des serveurs 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 + : ce que je conseille, c'est 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 datetime 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 que l'on pourrait penser, DATETIME est PLUS RAPIDE QUE 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 modifier 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 timestampchamp est un cas particulier du datetimechamp. Vous pouvez créertimestamp colonnes pour avoir des propriétés spéciales; il peut être configuré pour se mettre à jour lors de la création et / ou de la mise à jour.

En termes de base de données "plus grande", timestamp contient quelques déclencheurs de cas spéciaux.

Le bon choix dépend entièrement de ce que vous voulez faire.

TIMESTAMP est toujours en UTC (c'est-à-dire en secondes écoulées depuis le 01/01/1970, en UTC), et votre serveur MySQL le convertit automatiquement en date / heure pour le fuseau horaire de connexion. À long terme, TIMESTAMP est la voie à suivre car vous savez que vos données temporelles seront toujours en UTC. Par exemple, vous ne bousillerez pas vos dates si vous migrez vers un autre serveur ou si vous modifiez les paramètres de fuseau horaire sur votre serveur.

Remarque: le fuseau horaire de connexion par défaut est le fuseau horaire du serveur, mais il peut (devrait) être modifié par session (voir SET time_zone = ...).

Comparaison entre DATETIME, TIMESTAMP et DATE

Quelle est cette [.fraction]?

• Une valeur DATETIME ou TIMESTAMP peut inclure une partie de fraction de seconde de fin avec une précision allant jusqu'à quelques microsecondes (6 chiffres). En particulier, toute partie fractionnaire d'une valeur insérée dans une colonne DATETIME ou TIMESTAMP est stockée plutôt que supprimée. C'est bien sûr facultatif.

Sources:

• Référence des types de données MySQL Date / Time
• Référence des exigences de stockage MySQL

J'utiliserais toujours un horodatage Unix pour travailler avec MySQL et PHP. La raison principale en est la date par défaut méthode de en PHP utilise un horodatage comme paramètre, donc aucune analyse syntaxique n'est nécessaire.

Pour obtenir l'horodatage Unix actuel en PHP, faites-le time();
et faites -le dans MySQL SELECT UNIX_TIMESTAMP();.

Il convient de noter que dans MySQL, vous pouvez utiliser quelque chose dans le sens ci-dessous lors de la création de vos colonnes de table:

on update CURRENT_TIMESTAMP

Cela mettra à jour l'heure à laquelle vous modifiez une ligne à chaque instance et est parfois très utile pour les informations de dernière modification stockées. Cela ne fonctionne qu'avec horodatage, pas datetime cependant.

D'après mon expérience, si vous voulez un champ de date dans lequel l'insertion ne se produit qu'une seule fois et que vous ne voulez pas avoir de mise à jour ou toute autre action sur ce champ particulier, choisissez la date et l'heure .

Par exemple, considérons une usertable avec un champ DATE D'ENREGISTREMENT . Dans ce usertableau, si vous souhaitez connaître la dernière heure de connexion d'un utilisateur particulier, utilisez un champ de type horodatage pour que le champ soit mis à jour.

Si vous créez la table à partir de phpMyAdmin, le paramètre par défaut mettra à jour le champ d' horodatage lorsqu'une mise à jour de ligne se produit. Si votre horodatage déposé ne se met pas à jour avec la mise à jour des lignes, vous pouvez utiliser la requête suivante pour que le champ d' horodatage soit automatiquement mis à jour.

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, pas au format de fuseau horaire actuel comme le fait datetime. Et lorsque vous récupérez des données, l'horodatage les convertit à nouveau dans le fuseau horaire actuel.

Supposons donc que vous vous trouviez aux États-Unis et que vous obteniez des 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 mise à jour automatiquement lorsque sa ligne est mise à jour. Il peut donc être utile de suivre quand une ligne particulière a été mise à jour la dernière fois.

Pour plus de détails, vous pouvez lire l'article de blog Timestamp Vs Datetime .

J'utilise toujours un horodatage Unix, simplement pour maintenir la raison lorsque je traite de nombreuses informations datetime, en particulier lors de l'ajustement des fuseaux horaires, de l'ajout / de la 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 (que ce soit le code d'application ou les requêtes de base de données) en ce que vous utilisez l'arithmétique légère plutôt que d'ajouter / soustraire une date / heure plus lourde. les fonctions.

Une autre chose à considérer:

Si vous créez une application, vous ne savez jamais comment vos données peuvent être utilisées sur toute la ligne. Si vous devez comparer, par exemple, un ensemble d'enregistrements dans votre ensemble de données avec, par exemple, un ensemble d'éléments d'une API tierce, et dire, les mettre dans l'ordre chronologique, vous serez heureux d'avoir Horodatages 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 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 plutôt que les champs datetime, car les horodatages incluent implicitement le fuseau horaire. Donc, depuis le moment où l'application sera accessible à partir d'utilisateurs de différents fuseaux horaires et que vous souhaitez qu'ils voient les dates et les heures dans leur fuseau horaire local, ce type de champ le rend assez facile à faire que si les données étaient enregistrées dans des champs datetime .

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 en confiance en utilisant des horodatages. Pour ne pas dire les problèmes possibles lors du calcul des différences entre deux moments avec un changement d'heure entre les deux et nécessitant une précision de 1 heure ou moins.

Donc, pour résumer, j'apprécie les avantages de l'horodatage:

• prêt à l'emploi sur les applications internationales (multi fuseau horaire)
• migrations faciles entre les fuseaux horaires
• assez facile à calculer les différences (il suffit de soustraire les deux horodatages)
• ne vous inquiétez pas des dates d'entrée / sortie d'une période d'été

Pour toutes ces raisons, je choisis les champs UTC et d'horodatage lorsque cela est possible. Et j'évite les maux de tête;)

Méfiez-vous des modifications d'horodatage lorsque vous effectuez une instruction UPDATE sur une table. Si vous avez une table avec des colonnes 'Name' (varchar), 'Age' (int) et 'Date_Added' (horodatage) et que vous exécutez l'instruction DML suivante

UPDATE table
SET age = 30

puis chaque valeur unique dans votre colonne "Date_Added" serait remplacée par l'horodatage actuel.

Référence tirée de cet article:

Les principales différences:

TIMESTAMP permet de suivre les modifications apportées aux enregistrements et de les mettre à jour chaque fois que l'enregistrement est modifié. DATETIME utilisé pour stocker une valeur spécifique et statique qui n'est affectée par aucun changement dans les enregistrements.

TIMESTAMP est également affecté par différents paramètres liés à TIME ZONE. DATETIME est constant.

TIMESTAMP a converti en interne le fuseau horaire actuel en UTC pour le stockage et, pendant la récupération, reconverti dans le fuseau horaire actuel. DATETIME ne peut pas faire cela.

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 ′

+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
|                                       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.                                   |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+

Une autre différence entre l'horodatage et la date et l'heure réside dans l'horodatage dont la valeur par défaut est NULL.

J'ai trouvé une utilité inégalée dans la capacité de TIMESTAMP à se mettre à jour automatiquement en fonction de l'heure actuelle sans utiliser de déclencheurs inutiles. C'est juste moi cependant, bien que TIMESTAMP soit UTC comme il a été dit.

Il peut garder une trace sur différents fuseaux horaires, donc si vous devez afficher une heure relative par exemple, l'heure UTC est ce que vous souhaitez.

La principale différence est

• un INDEX sur l'horodatage - travaux
• un INDEX sur Datetime - ne fonctionne pas

regardez ce post pour voir les problèmes d'indexation Datetime

J'ai cessé d'utiliser datetimedans mes applications après avoir rencontré de nombreux problèmes et bugs liés aux fuseaux horaires. À mon humble avis, l'utilisation timestampest meilleure que datetimedans la plupart des cas .

Quand vous demandez quel est le temps? et la réponse vient comme 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 d'heures sans le fuseau horaire signifie que votre application ne traite que d'un seul fuseau horaire, mais les horodatages vous offrent les avantages datetimeet la flexibilité d'afficher le même moment exact dans différents fuseaux horaires.

Voici quelques cas qui vous feront regretter d'utiliser datetimeet souhaiteront avoir stocké vos données dans des horodatages.

1. Pour le confort de vos clients, vous voulez leur montrer les heures en fonction de leurs fuseaux horaires préférés sans les obliger à faire le calcul et convertir l'heure en leur fuseau horaire significatif. tout ce dont vous avez besoin est de changer le fuseau horaire et tout votre code d'application sera le même. (En fait, vous devez toujours définir le fuseau horaire au début de l'application, ou demander un traitement dans le cas d'applications PHP)

   SET time_zone = '+2:00';

2. vous avez changé le pays dans lequel vous séjournez et poursuivez votre travail de maintenance des données tout en les visualisant dans un fuseau horaire différent (sans modifier les données réelles).

3. vous acceptez les données de différents clients du monde entier, chacun insère l'heure dans son fuseau horaire.

En bref

datetime = l'application prend en charge 1 fuseau horaire (pour l'insertion et la sélection)

timestamp = l'application prend en charge n'importe quel fuseau horaire (pour l'insertion et la sélection)

Cette réponse est uniquement pour mettre en évidence la flexibilité et la facilité des horodatages en ce qui concerne les fuseaux horaires, elle ne couvre pas d'autres différences telles que la taille ou la plage de colonnes ou la fraction .

Je préfère utiliser l'horodatage afin de tout garder dans un format brut commun et de formater les données en code PHP ou dans votre requête SQL. Il y a des cas où il est utile dans votre code pour tout garder en quelques secondes.

A TIMESTAMPnécessite 4 octets, tandis que a DATETIMErequiert 8 octets.

J'aime un horodatage Unix, car vous pouvez convertir en nombres et vous soucier du nombre. De plus, vous ajoutez / soustrayez et obtenez des durées, etc. Convertissez ensuite le résultat en Date dans n'importe quel format. Ce code découvre combien de temps en minutes s'est écoulé 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);