Para o exemplo específico que você usou em sua pergunta (ano 1200), tecnicamente as coisas funcionarão.

Em geral, entretanto, timestamps são desaconselháveis ​​para este uso. Primeiro, a limitação de alcance é arbitrária:no MySQL é 1º de janeiro de 1000. Se você está trabalhando com coisas do século 12-13, as coisas vão bem... mas se em algum momento você precisa adicionar algo mais antigo (século 10 ou anterior), a data será quebrada miseravelmente e a correção do problema exigirá a reformatação de todas as suas datas históricas em algo mais adequado.

Os carimbos de data/hora são normalmente representados como inteiros brutos, com um determinado "intervalo de marcação" e "ponto de época", de modo que o número é de fato o número de tiques decorridos desde a época até a data representada (ou vice-versa para datas negativas). Isso significa que, como em qualquer tipo de dados fixo com inteiro, o conjunto de valores representáveis ​​é finito. A maioria dos formatos de carimbo de data/hora que conheço sobre o intervalo de sacrifício em favor da precisão, principalmente porque os aplicativos que precisam executar aritmética de tempo geralmente precisam fazê-lo com uma precisão decente; enquanto os aplicativos que precisam trabalhar com datas históricas raramente precisam realizar aritmética séria.

Em outras palavras, os carimbos de data/hora são para precisos representação de datas. A precisão do segundo (ou mesmo fração de segundo) não faz sentido para datas históricas:você poderia me dizer, até os milissegundos, quando Henrique VIII foi coroado rei da Inglaterra?

No caso do MySQL, o formato é inerentemente definido como "anos de 4 dígitos", então qualquer otimização relacionada pode se basear na suposição de que o ano terá 4 dígitos, ou que a string inteira terá exatamente 10 caracteres ("yyyy- mm-dd"), etc. É apenas uma questão de sorte que a data que você mencionou no seu título ainda se encaixa, mas mesmo confiar nisso ainda é perigoso:além do que o próprio banco de dados pode armazenar, você precisa estar ciente do que o resto de sua pilha de servidores pode manipular. Por exemplo, se você estiver usando PHP para interagir com seu banco de dados, tentar lidar com datas históricas provavelmente falhará em algum ponto ou outro (em um ambiente de 32 bits, o intervalo para carimbos de data e hora no estilo UNIX é de 13 de dezembro de 1901 a 19 de janeiro de 2038).

Em resumo:o MySQL armazenará corretamente qualquer data com ano de 4 dígitos; mas, em geral, o uso de carimbos de data e hora para datas históricas quase garante problemas e dores de cabeça com mais frequência. Eu aconselho fortemente contra esse uso.

Espero que isto ajude.

Editar/adicionar:

Eu não acho que nenhum banco de dados tenha muito suporte para esse tipo de data:os aplicativos que o usam geralmente têm o suficiente com representação de string/texto. Na verdade, para datas no ano 1 e posteriores, uma representação textual produzirá até mesmo ordenação/comparações corretas (desde que a data seja representada por ordem de magnitude:ordem y,m,d). As comparações serão interrompidas, no entanto, se datas "negativas" também estiverem envolvidas (elas ainda seriam comparadas como anteriores a qualquer data positiva, mas comparar duas datas negativas produziria um resultado invertido).

Se você precisar apenas de datas do Ano 1 e posteriores, ou se não precisar de classificação, poderá facilitar muito sua vida usando strings.

Caso contrário, a melhor abordagem é usar algum tipo de número e definir seu próprio "intervalo de marcação" e "ponto de época". Um bom intervalo pode ser dias (a menos que você realmente precise de mais precisão, mas mesmo assim você pode confiar em números "reais" (ponto flutuante) em vez de números inteiros); e uma época razoável poderia ser 1º de janeiro, 1º de janeiro. O principal problema será transformar esses valores em sua representação de texto e vice-versa. Você precisa ter em mente os seguintes detalhes:

• Os anos bissextos têm um dia a mais.
• A regra para anos bissextos era "qualquer múltiplo de 4" até 1582, quando mudou do calendário juliano para o gregoriano e se tornou "múltiplo de 4, exceto aqueles que são múltiplos de 100, a menos que também sejam múltiplos de 400".
• O último dia do calendário juliano foi 4 de outubro de 1582. O dia seguinte, o primeiro do calendário gregoriano, foi 15 de outubro de 1582. Foram pulados 10 dias para que o novo calendário correspondesse novamente às estações.
>
• Como declarado nos comentários, as duas regras acima variam de acordo com o país:os estados papais e alguns países católicos adotaram o novo calendário nas datas indicadas, mas muitos outros países levaram mais tempo para fazê-lo (o último foi a Turquia em 1926) . Isso significa que qualquer data entre a bula papal em 1582 e a última adoção em 1926 será ambígua sem contexto geográfico e ainda mais complexa de processar.
• Não há "ano 0":o ano anterior ao ano 1 era o ano -1 ou o ano 1 AEC.

Tudo isso requer funções de analisador e formador bastante elaboradas, mas além das muitas quebras caso a caso, não há muita complexidade (seria tedioso codificar, mas bastante direto). O uso de números como representação subjacente garante a classificação/comparação correta para qualquer par de valores.

Sabendo disso, agora é sua escolha adotar a abordagem que melhor se adapta às suas necessidades.