Test av formulär leder förr eller senare till datumrelaterade frågor; hur ser ett datum ut, hur långt tillbaka i tiden ska vi tillåta, osv. Igår stötte jag på ett intressant problem med hanteringen av historiska datum.

Tydligen hanterar SQL-servers datatyp DateTime inte datum tidigare än 1753-01-01 utan skickar helt sonika tillbaka ett fel som berättar att -det här hanteras minsann inte.

Informationen förmedlades via IM till skaparen av funktionen som, till min förvåning, inte kände till problemet. Google hjälpte mig hitta en trolig anledning till varför just 1753 hade valts som ett första år. Tydligen justerades kalendern 1752 vilket innebar att 12 dagar av det året helt magiskt försvann. Man kan ju tänka sig att det inte är något man vill hantera i sina redan komplexa beräkningar av datum hit och dit, så gränsen drogs efter att dylika övningar men kalenderjusteringar var över; 1753.

Men hur kunde hela världen synkroniseras att justera kalendern just 1753?
Det kunde den inte. Sverige justerade först året efter, alltså just 1753. Det innebär i sin tur att datatypen DateTime i SQL-server inte är Sverigekompatibel. Låt vara att det gäller för årtal som sällan är relevanta men ska man bygga en databas med historiska årtal för, till exempel, en webbplats om det historiska Stockholm, så bör man nog känna till det här problemet.

Såklart har flera stött på problemet redan och förslag på lösningar fanns det gott om. En ganska klipsk lösning var att lägga på femtusen år på tidigare årtal. Klipsk för att den är enkel och verkar rimlig. Men vad jag älskar med internet är självsaneringen. Lösningen blev snabbt ifrågasatt; Vad händer då med skottår? Hur löser det problemet med de 12 försvunna dagarna?

En intressant lärdom var det i alla fall!