För det specifika exemplet du använde på din fråga (år 1200), tekniskt sett kommer saker att fungera.
I allmänhet är dock tidsstämplar inte tillrådliga för denna användning. För det första är räckviddsbegränsningen godtycklig:i MySQL är det 1 januari 1000. Om du arbetar med grejer från 1100- och 1200-talet går det bra... men om någon gång du måste lägga till något äldre (900-talet eller tidigare), datumet kommer att gå sönder, och för att åtgärda problemet måste du formatera om alla dina historiska datum till något mer adekvat.
Tidsstämplar representeras normalt som råa heltal, med ett givet "tick-intervall" och "epokpunkt", så siffran är verkligen antalet bockar som har förflutit sedan epoken till det representerade datumet (eller viceversa för negativa datum). Detta betyder att, som med alla fasta-med heltalsdatatyp, är uppsättningen representerbara värden ändlig. De flesta tidsstämpelformat jag känner till om offerintervall till förmån för precision, mest för att applikationer som behöver utföra tidsarithmetik ofta behöver göra det med en anständig precision; medan program som behöver arbeta med historiska datum mycket sällan behöver utföra seriös aritmetik.
Med andra ord, tidsstämplar är avsedda för exakt representation av datum. Andra (eller till och med en bråkdel av en sekund) precision ger ingen mening för historiska datum:kan du berätta för mig, ner till millisekunder, när Henrik den 8:e kröntes till kung av England?
När det gäller MySQL är formatet i sig definierat som "4-siffriga år", så all relaterad optimering kan förlita sig på antagandet att året kommer att ha fyra siffror, eller att hela strängen kommer att ha exakt 10 tecken ("åååå- mm-dd"), etc. Det är bara en tur att datumet du nämnde på din titel fortfarande passar, men även att lita på det är fortfarande farligt:förutom vad DB själv kan lagra, måste du vara medveten om vad resten av din serverstack kan manipulera. Om du till exempel använder PHP för att interagera med din databas, är det mycket sannolikt att försök att hantera historiska datum kraschar någon gång (i en 32-bitarsmiljö är intervallet för tidsstämplar i UNIX-stil 13 december 1901 till och med 19 januari 2038).
Sammanfattningsvis:MySQL lagrar alla datum korrekt med ett 4-siffrigt årtal; men i allmänhet är det nästan garanterat att använda tidsstämplar för historiska datum att utlösa problem och huvudvärk oftare än inte. Jag avråder starkt från sådan användning.
Hoppas detta hjälper.
Redigera/tillägg:
Jag tror inte att någon DB har för mycket stöd för den här typen av datum:applikationer som använder den har oftast tillräckligt med sträng-/text-representation. Faktiskt, för datum på år 1 och senare, kommer en textrepresentation till och med att ge korrekt sortering/jämförelser (så länge som datumet representeras av storleksordning:y,m,d ordning). Jämförelser kommer dock att gå sönder om "negativa" datum också är inblandade (de skulle fortfarande jämföras som tidigare än något positivt, men att jämföra två negativa datum skulle ge ett omvänt resultat).
Om du bara behöver år 1 och senare datum, eller om du inte behöver sortering, kan du göra ditt liv mycket enklare genom att använda strängar.
Annars är det bästa tillvägagångssättet att använda något slags nummer, och definiera ditt eget "tick-intervall" och "epokpunkt". Ett bra intervall kan vara dagar (om du inte verkligen behöver mer precision, men även då kan du lita på "riktiga" (flytande) tal istället för heltal); och en rimlig epok kan vara 1 januari, 1. Huvudproblemet kommer att vända dessa värden till deras textrepresentation, och vice versa. Du måste tänka på följande detaljer:
- Skotår har en extra dag.
- Regeln för skottår var "vilken som helst multipel av 4" fram till 1582, då den ändrades från den julianska till den gregorianska kalendern och blev "multipel av 4 förutom de som är multiplar av 100 om de inte också är multiplar av 400".
- Sista dagen i den julianska kalendern var den 4 oktober 1582. Nästa dag, den första i den gregorianska kalendern, var den 15 oktober 1582. 10 dagar hoppades över för att den nya kalendern skulle matcha årstiderna igen. >
- Som anges i kommentarerna varierar de två reglerna ovan från land till land:Påvliga stater och vissa katolska länder antog den nya kalendern på de angivna datumen, men många andra länder tog längre tid att göra det (det sista var Turkiet 1926) . Detta innebär att varje datum mellan den påvliga tjuren 1582 och den sista adoptionen 1926 kommer att vara tvetydig utan geografisk kontext, och ännu mer komplicerad att bearbeta.
- Det finns inget "år 0":året före år 1 var år -1, eller år 1 fvt.
Allt detta kräver ganska utarbetade parser- och formateringsfunktioner, men utöver de många brytningarna från fall till fall finns det egentligen inte så mycket komplexitet (det skulle vara tråkigt att koda, men ganska enkelt). Användningen av siffror som den underliggande representationen säkerställer korrekt sortering/jämförelse för alla värdepar.
När du vet detta är det nu ditt val att ta det tillvägagångssätt som bättre passar dina behov.