Pour l'exemple spécifique que vous avez utilisé dans votre question (année 1200), techniquement, les choses fonctionneront.
En général, cependant, les horodatages sont déconseillés pour ces utilisations. Tout d'abord, la limitation de la plage est arbitraire :dans MySQL, c'est le 1er janvier 1000. Si vous travaillez avec des trucs du 12e au 13e siècle, tout se passe bien... mais si à un moment donné vous devez ajouter quelque chose de plus ancien (10ème siècle ou plus tôt), la date se cassera lamentablement, et résoudre le problème nécessitera de reformater toutes vos dates historiques en quelque chose de plus adéquat.
Les horodatages sont normalement représentés sous forme d'entiers bruts, avec un "intervalle de tick" et un "point d'époque" donnés, de sorte que le nombre est bien le nombre de ticks écoulés depuis l'époque jusqu'à la date représentée (ou vice versa pour les dates négatives). Cela signifie que, comme pour tout type de données fixe avec entier, l'ensemble des valeurs représentables est fini. La plupart des formats d'horodatage que je connais sacrifient la plage au profit de la précision, principalement parce que les applications qui doivent effectuer des calculs temporels doivent souvent le faire avec une précision décente ; tandis que les applications qui doivent travailler avec des dates historiques ont très rarement besoin d'effectuer des opérations arithmétiques sérieuses.
En d'autres termes, les horodatages sont destinés à être précis représentation des dates. La précision de seconde (ou même de fraction de seconde) n'a aucun sens pour les dates historiques :pourriez-vous me dire, à la milliseconde près, quand Henri VIII a-t-il été couronné roi d'Angleterre ?
Dans le cas de MySQL, le format est intrinsèquement défini comme "années à 4 chiffres", donc toute optimisation associée peut reposer sur l'hypothèse que l'année aura 4 chiffres, ou que la chaîne entière aura exactement 10 caractères ("yyyy- mm-jj"), etc. C'est juste une question de chance que la date que vous avez mentionnée sur votre titre corresponde toujours, mais même s'y fier est toujours dangereux :en plus de ce que la base de données elle-même peut stocker, vous devez être conscient de ce que reste de votre pile de serveurs peut manipuler. Par exemple, si vous utilisez PHP pour interagir avec votre base de données, essayer de gérer les dates historiques est très susceptible de se bloquer à un moment ou à un autre (sur un environnement 32 bits, la plage d'horodatages de style UNIX va du 13 décembre 1901 au 19 janvier 2038).
En résumé :MySQL stockera correctement toute date avec une année à 4 chiffres; mais en général, l'utilisation d'horodatages pour les dates historiques est presque garantie de déclencher des problèmes et des maux de tête le plus souvent. Je déconseille fortement une telle utilisation.
J'espère que cela vous aidera.
Modifier/ajouter :
Je ne pense pas qu'une base de données ait trop de support pour ce type de dates:les applications qui l'utilisent le plus souvent en ont assez avec la représentation de chaîne/texte. En fait, pour les dates de l'année 1 et suivantes, une représentation textuelle donnera même un tri / des comparaisons corrects (tant que la date est représentée par ordre de grandeur :ordre a, m, j). Cependant, les comparaisons seront interrompues si des dates "négatives" sont également impliquées (elles seraient toujours comparables comme antérieures à toute date positive, mais la comparaison de deux dates négatives donnerait un résultat inversé).
Si vous n'avez besoin que des dates de l'année 1 et des dates ultérieures, ou si vous n'avez pas besoin de tri, vous pouvez vous simplifier la vie en utilisant des chaînes.
Sinon, la meilleure approche consiste à utiliser une sorte de nombre et à définir votre propre "intervalle de coche" et "point d'époque". Un bon intervalle pourrait être des jours (à moins que vous n'ayez vraiment besoin de plus de précision, mais même dans ce cas, vous pouvez compter sur des nombres "réels" (à virgule flottante) au lieu d'entiers); et une époque raisonnable pourrait être le 1er janvier 1. Le principal problème sera de transformer ces valeurs en leur représentation textuelle, et vice versa. Vous devez garder à l'esprit les détails suivants :
- Les années bissextiles ont un jour supplémentaire.
- La règle pour les années bissextiles était "tout multiple de 4" jusqu'en 1582, date à laquelle il est passé du calendrier julien au calendrier grégorien et est devenu "un multiple de 4 sauf ceux qui sont des multiples de 100 à moins qu'ils ne soient aussi des multiples de 400".
- Le dernier jour du calendrier julien était le 4 octobre 1582. Le lendemain, le premier du calendrier grégorien, était le 15 octobre 1582. 10 jours ont été sautés pour que le nouveau calendrier corresponde à nouveau aux saisons.
- Comme indiqué dans les commentaires, les deux règles ci-dessus varient selon les pays :les États pontificaux et certains pays catholiques ont adopté le nouveau calendrier aux dates indiquées, mais de nombreux autres pays ont mis plus de temps à le faire (le dernier étant la Turquie en 1926) . Cela signifie que toute date entre la bulle papale en 1582 et la dernière adoption en 1926 sera ambiguë sans contexte géographique, et encore plus complexe à traiter.
- Il n'y a pas d'"année 0" :l'année précédant l'année 1 était l'année -1, ou l'année 1 avant notre ère.
Tout cela nécessite des fonctions d'analyseur et de formatage assez élaborées, mais au-delà des nombreuses ruptures au cas par cas, il n'y a pas vraiment trop de complexité (ce serait fastidieux à coder, mais assez simple). L'utilisation de nombres comme représentation sous-jacente garantit un tri/comparaison correct pour toute paire de valeurs.
Sachant cela, vous avez maintenant le choix d'adopter l'approche qui correspond le mieux à vos besoins.
