For det specifikke eksempel, du brugte på dit spørgsmål (år 1200), vil tingene teknisk fungere.
Generelt er tidsstempler dog ikke tilrådelige til denne anvendelse. For det første er rækkeviddebegrænsningen vilkårlig:i MySQL er det 1. januar 1000. Hvis du arbejder med ting fra det 12.-13. århundrede, går det fint... men hvis på et tidspunkt du skal tilføje noget ældre (10. århundrede eller tidligere), datoen vil elendigt gå i stykker, og løsning af problemet vil kræve omformatering af alle dine historiske datoer til noget mere passende.
Tidsstempler er normalt repræsenteret som rå heltal med et givet "tick-interval" og "epokepunkt", så tallet er faktisk antallet af kryds, der er forløbet siden epoken til den repræsenterede dato (eller omvendt for negative datoer). Dette betyder, som med enhver fast-med heltal datatype, at sættet af repræsentative værdier er begrænset. De fleste tidsstempelformater, jeg kender, om offerområde til fordel for præcision, mest fordi applikationer, der skal udføre tidsregning, ofte skal gøre det med en anstændig præcision; mens applikationer, der skal arbejde med historiske datoer, meget sjældent skal udføre seriøs aritmetik.
Med andre ord, tidsstempler er beregnet til præcise repræsentation af datoer. Anden (eller endda brøkdel af sekund) præcision giver ingen mening for historiske datoer:kunne du fortælle mig, helt ned til millisekunderne, hvornår blev Henrik den 8. kronet som konge af England?
I tilfælde af MySQL er formatet i sagens natur defineret som "4-cifrede år", så enhver relateret optimering kan stole på antagelsen om, at året vil have 4 cifre, eller at hele strengen vil have præcis 10 tegn ("åååå- mm-dd") osv. Det er bare et spørgsmål om held, at den dato, du nævnte på din titel, stadig passer, men selv at stole på det er stadig farligt:Udover hvad DB'en selv kan gemme, skal du være opmærksom på, hvad resten af din serverstak kan manipulere. Hvis du f.eks. bruger PHP til at interagere med din database, er det meget sandsynligt, at forsøg på at håndtere historiske datoer går ned på et eller andet tidspunkt (i et 32-bit miljø er intervallet for UNIX-stil tidsstempler 13. december 1901 til og med 19. januar 2038).
Sammenfattende:MySQL gemmer korrekt enhver dato med et 4-cifret årstal; men generelt vil brug af tidsstempler for historiske datoer næsten garanteret udløse problemer og hovedpine oftere end ikke. Jeg fraråder kraftigt sådan brug.
Håber dette hjælper.
Rediger/tilføjelse:
Jeg tror ikke, at nogen DB har for meget støtte til denne slags datoer:applikationer, der bruger det, har oftest nok med streng-/tekst-repræsentation. Faktisk, for datoer på år 1 og senere, vil en tekstlig repræsentation endda give korrekt sortering / sammenligninger (så længe datoen er repræsenteret i størrelsesorden:y,m,d orden). Sammenligninger vil imidlertid bryde, hvis "negative" datoer også er involveret (de ville stadig sammenlignes med tidligere end enhver positiv, men sammenligning af to negative datoer ville give et omvendt resultat).
Hvis du kun har brug for år 1 og senere datoer, eller hvis du ikke har brug for sortering, så kan du gøre dit liv meget lettere ved at bruge strenge.
Ellers er den bedste tilgang at bruge en form for tal og definere dit eget "tick-interval" og "epokepunkt". Et godt interval kunne være dage (medmindre du virkelig har brug for yderligere præcision, men selv da kan du stole på "rigtige" (flydende) tal i stedet for heltal); og en rimelig epoke kunne være 1. januar, 1. Hovedproblemet vil være at vende disse værdier til deres tekstrepræsentation og omvendt. Du skal huske på følgende detaljer:
- Skidår har én ekstra dag.
- Reglen for skudår var "ethvert multiplum af 4" indtil 1582, hvor det ændrede sig fra den julianske til den gregorianske kalender og blev "multiplum af 4 undtagen dem, der er multipla af 100, medmindre de også er multipla af 400".
- Den sidste dag i den julianske kalender var den 4. oktober 1582. Den næste dag, den første i den gregorianske kalender, var den 15. oktober 1582. 10 dage blev sprunget over for at få den nye kalender til at matche årstiderne igen. >
- Som angivet i kommentarerne varierer de to regler ovenfor fra land til land:Pavelige stater og nogle katolske lande vedtog den nye kalender på de angivne datoer, men mange andre lande tog længere tid at gøre det (det sidste var Tyrkiet i 1926) . Det betyder, at enhver dato mellem den pavelige tyr i 1582 og den sidste adoption i 1926 vil være tvetydig uden geografisk kontekst og endnu mere kompleks at behandle.
- Der er intet "år 0":året før år 1 var år -1 eller år 1 fvt.
Alt dette kræver ret komplicerede parser- og formateringsfunktioner, men ud over de mange brud fra sag til sag er der egentlig ikke for meget kompleksitet (det ville være kedeligt at kode, men ret ligetil). Brugen af tal som den underliggende repræsentation sikrer korrekt sortering/sammenligning for ethvert værdipar.
Når du ved dette, er det nu dit valg at tage den tilgang, der passer bedre til dine behov.