Voor het specifieke voorbeeld dat je voor je vraag hebt gebruikt (jaar 1200), zal het technisch gezien werken.
In het algemeen zijn tijdstempels echter niet aan te raden voor dit gebruik. Ten eerste is de bereikbeperking willekeurig:in MySQL is dit 1 januari 1000. Als je met 12-13e-eeuwse dingen werkt, gaat het goed... je moet iets ouder toevoegen (10e eeuw of eerder), de datum zal jammerlijk breken en om het probleem op te lossen, moeten al je historische datums opnieuw worden geformatteerd in iets dat meer geschikt is.
Tijdstempels worden normaal gesproken weergegeven als onbewerkte gehele getallen, met een bepaald "tick-interval" en "epoch-punt", dus het aantal is inderdaad het aantal tikken dat is verstreken sinds het tijdperk tot de weergegeven datum (of omgekeerd voor negatieve datums). Dit betekent dat, zoals bij elk datatype met vast-met-geheel getal, de reeks representeerbare waarden eindig is. De meeste tijdstempelformaten die ik ken, zijn een offerbereik ten gunste van precisie, vooral omdat toepassingen die tijdberekeningen moeten uitvoeren, dit vaak met een behoorlijke precisie moeten doen; terwijl applicaties die met historische datums moeten werken zeer zelden serieuze rekenkundige bewerkingen hoeven uit te voeren.
Met andere woorden, tijdstempels zijn bedoeld voor precieze weergave van datums. Een seconde (of zelfs een fractie van een seconde) precisie heeft geen zin voor historische data:zou je me kunnen vertellen, tot op de milliseconden, wanneer Hendrik de 8e werd gekroond tot koning van Engeland?
In het geval van MySQL is het formaat inherent gedefinieerd als "jaar van 4 cijfers", dus elke gerelateerde optimalisatie kan gebaseerd zijn op de veronderstelling dat het jaar 4 cijfers zal hebben, of dat de hele reeks precies 10 tekens zal hebben ("yyyy- mm-dd"), enz. Het is gewoon een kwestie van geluk dat de datum die u op uw titel noemde nog steeds past, maar zelfs daarop vertrouwen is nog steeds gevaarlijk:naast wat de DB zelf kan opslaan, moet u zich bewust zijn van wat de rest van je serverstack kan manipuleren. Als u bijvoorbeeld PHP gebruikt voor interactie met uw database, is de kans groot dat het proberen om historische datums af te handelen op een of ander moment vastloopt (in een 32-bits omgeving is het bereik voor UNIX-tijdstempels van 13 december 1901 tot en met 19 januari 2038).
Samengevat:MySQL slaat elke datum met een jaartal van 4 cijfers correct op; maar over het algemeen is het bijna gegarandeerd dat het gebruik van tijdstempels voor historische datums vaker problemen en hoofdpijn veroorzaakt. Ik raad dergelijk gebruik ten zeerste af.
Ik hoop dat dit helpt.
Bewerken/toevoegen:
Ik denk niet dat een DB te veel ondersteuning biedt voor dit soort datums:toepassingen die het gebruiken, hebben meestal genoeg aan string-/tekst-representatie. Voor datums op jaar 1 en later zal een tekstuele weergave zelfs correcte sortering / vergelijkingen opleveren (zolang de datum wordt weergegeven in orde van grootte:y,m,d orde). Vergelijkingen zullen echter mislukken als er ook "negatieve" datums in het spel zijn (ze zouden nog steeds vergelijken als eerder dan een positieve, maar het vergelijken van twee negatieve datums zou een omgekeerd resultaat opleveren).
Als je alleen jaar 1 en latere datums nodig hebt, of als je niet hoeft te sorteren, dan kun je je leven een stuk gemakkelijker maken door strings te gebruiken.
Anders is de beste aanpak om een soort nummer te gebruiken en je eigen "tick interval" en "epoch point" te definiëren. Een goed interval kan dagen zijn (tenzij je echt meer precisie nodig hebt, maar zelfs dan kun je vertrouwen op "echte" (floating-point) getallen in plaats van gehele getallen); en een redelijk tijdperk zou 1 januari 1 kunnen zijn. Het grootste probleem zal zijn om deze waarden om te zetten in hun tekstrepresentatie, en omgekeerd. Houd rekening met de volgende details:
- Schrikkeljaren hebben één dag extra.
- De regel voor schrikkeljaren was "elk veelvoud van 4" tot 1582, toen het veranderde van de Juliaanse in de Gregoriaanse kalender en "veelvoud van 4 werd behalve die veelvouden van 100 tenzij ze ook veelvouden van 400 zijn".
- De laatste dag van de Juliaanse kalender was 4 oktober 1582. De volgende dag, de eerste dag van de Gregoriaanse kalender, was 15 oktober 1582. Er werden 10 dagen overgeslagen om de nieuwe kalender weer overeen te laten komen met de seizoenen.
- Zoals vermeld in de opmerkingen, verschillen de twee bovenstaande regels per land:pauselijke staten en sommige katholieke landen hebben de nieuwe kalender op de vermelde data aangenomen, maar veel andere landen deden er langer over (de laatste was Turkije in 1926) . Dit betekent dat elke datum tussen de pauselijke bul in 1582 en de laatste goedkeuring in 1926 dubbelzinnig zal zijn zonder geografische context, en zelfs nog complexer om te verwerken.
- Er is geen "jaar 0":het jaar voor jaar 1 was jaar -1, of jaar 1 BCE.
Dit alles vereist behoorlijk uitgebreide parser- en formaterfuncties, maar afgezien van de vele breuken per geval is er niet echt te veel complexiteit (het zou vervelend zijn om te coderen, maar vrij eenvoudig). Het gebruik van getallen als onderliggende representatie zorgt voor een correcte sortering/vergelijking voor elk paar waarden.
Dit wetende, is het nu jouw keuze om de aanpak te kiezen die beter bij je behoeften past.