Para el ejemplo específico que usó en su pregunta (año 1200), técnicamente todo funcionará.
En general, sin embargo, las marcas de tiempo no son recomendables para estos usos. En primer lugar, la limitación del rango es arbitraria:en MySQL es el 1 de enero de 1000. Si está trabajando con cosas del siglo 12-13, las cosas van bien... pero si en algún momento necesita agregar algo más antiguo (siglo X o anterior), la fecha se romperá miserablemente y solucionar el problema requerirá volver a formatear todas sus fechas históricas en algo más adecuado.
Las marcas de tiempo normalmente se representan como números enteros sin procesar, con un "intervalo de ticks" y un "punto de época" dados, por lo que el número es de hecho el número de ticks transcurridos desde la época hasta la fecha representada (o viceversa para fechas negativas). Esto significa que, como con cualquier tipo de datos fijo con entero, el conjunto de valores representables es finito. La mayoría de los formatos de marca de tiempo que conozco sacrifican el rango en favor de la precisión, principalmente porque las aplicaciones que necesitan realizar aritmética de tiempo a menudo necesitan hacerlo con una precisión decente; mientras que las aplicaciones que necesitan trabajar con fechas históricas rara vez necesitan realizar operaciones aritméticas serias.
En otras palabras, las marcas de tiempo están pensadas para precisos Representación de fechas. La precisión de segundo (o incluso fracción de segundo) no tiene sentido para las fechas históricas:¿podría decirme, hasta los milisegundos, cuándo fue coronado Enrique VIII como rey de Inglaterra?
En el caso de MySQL, el formato se define inherentemente como "años de 4 dígitos", por lo que cualquier optimización relacionada puede basarse en la suposición de que el año tendrá 4 dígitos, o que la cadena completa tendrá exactamente 10 caracteres ("yyyy- mm-dd"), etc. Es solo una cuestión de suerte que la fecha que mencionaste en tu título aún se ajuste, pero incluso confiar en eso sigue siendo peligroso:además de lo que la base de datos en sí puede almacenar, debes saber qué el resto de la pila de su servidor puede manipular. Por ejemplo, si está utilizando PHP para interactuar con su base de datos, es muy probable que al tratar de manejar fechas históricas falle en algún momento (en un entorno de 32 bits, el rango para las marcas de tiempo de estilo UNIX es del 13 de diciembre de 1901 al 19 de enero de 2038).
En resumen:MySQL almacenará correctamente cualquier fecha con un año de 4 dígitos; pero, en general, es casi seguro que el uso de marcas de tiempo para fechas históricas desencadenará problemas y dolores de cabeza la mayoría de las veces. Recomiendo enfáticamente contra tal uso.
Espero que esto ayude.
Editar/añadir:
No creo que ninguna base de datos tenga demasiado soporte para este tipo de fechas:las aplicaciones que lo usan a menudo tienen suficiente con la representación de cadena/texto. En realidad, para fechas del año 1 y posteriores, una representación textual incluso producirá clasificaciones/comparaciones correctas (siempre que la fecha se represente por orden de magnitud:orden a, m, d). Sin embargo, las comparaciones se romperán si también están involucradas fechas "negativas" (todavía se compararían como anteriores a cualquier fecha positiva, pero comparar dos fechas negativas produciría un resultado inverso).
Si solo necesita las fechas del año 1 y posteriores, o si no necesita clasificar, entonces puede hacer su vida mucho más fácil usando cadenas.
De lo contrario, el mejor enfoque es usar algún tipo de número y definir su propio "intervalo de marca" y "punto de época". Un buen intervalo podría ser días (a menos que realmente necesite más precisión, pero incluso entonces puede confiar en números "reales" (coma flotante) en lugar de números enteros); y una época razonable podría ser el 1 de enero de 1. El principal problema será convertir estos valores en su representación de texto, y viceversa. Debe tener en cuenta los siguientes detalles:
- Los años bisiestos tienen un día extra.
- La regla para los años bisiestos era "cualquier múltiplo de 4" hasta 1582, cuando cambió del calendario juliano al gregoriano y se convirtió en "múltiplo de 4 excepto aquellos que son múltiplos de 100 a menos que también sean múltiplos de 400".
- El último día del calendario juliano fue el 4 de octubre de 1582. El día siguiente, el primero del calendario gregoriano, fue el 15 de octubre de 1582. Se omitieron 10 días para que el nuevo calendario coincidiera nuevamente con las estaciones.
- Como se indicó en los comentarios, las dos reglas anteriores varían según el país:los estados papales y algunos países católicos adoptaron el nuevo calendario en las fechas indicadas, pero muchos otros países tardaron más en hacerlo (el último fue Turquía en 1926) . Esto significa que cualquier fecha entre la bula papal en 1582 y la última adopción en 1926 será ambigua sin contexto geográfico, y aún más compleja de procesar.
- No existe el "año 0":el año anterior al año 1 fue el año -1, o el año 1 a. C.
Todo esto requiere funciones de analizador y formateador bastante elaboradas, pero más allá de las muchas rupturas caso por caso, no hay demasiada complejidad (sería tedioso programar, pero bastante sencillo). El uso de números como representación subyacente garantiza la clasificación/comparación correcta de cualquier par de valores.
Sabiendo esto, ahora es su elección tomar el enfoque que mejor se adapte a sus necesidades.
