In english please!

önskar ställa en fråga omkring sekelskiftet

Sekelskiftet

Som du säkert läst i datapressen så är mänsklighetens nästa stora problem år 2000 och hur våra databaser och datasystem ska överleva sekelskiftet.

Likt alla andra stora problem sönderfaller detta vid närmare betraktande i flera mindre problem.

För det första lär det finnas en bugg i bioset på äldre PC-ar som gör att när man startar dem den första januari 2000 kommer datumet ( i klockan) att ha backat till 1sta jan 1980 Det ska gå att ställa om klockan till 2000 men efter nästa boot så återvänder den envist till 1980. Anledningen till detta påstås vara att man använt för få bit-ar till att lagra datum när PC-n är avslagen. Om allt detta är sant skulle det vara en jämn 2potens dagar mellan dessa datum vilket inte stämmer. Troligen är det så att vissa (gamla) PC-ar kommer att backa 32K dagar någon gång år 2000.

För det andra så får man problem om man lagrar datum i klartext med 2 årtalssiffror. Det går bra att lagra 000101 men när man ska jämföra det med 991231 så blir det mindre vilket tolkas som att första januari 2000 är tidigare än sista december 1999!

 

I en modern databasmiljö som UniVerse lagrar man datum som antal dagar efter den sista december 1967 som alltså är dag 0 och undviker därmed problemet. Ett system skrivet UniVerse kan naturligtvis få problem ändå. T.ex kan man ha definierat en variabel eller I-deskriptor bokföringsår som 2-ställigt årtal. Om man sen sorterar på bokföringsår kommer 2000 före 1999 eller om man gör ett urval på bokföringsår < 01 så komer inte 98,99 med och omvänt om man väljer bokföringsår > 98 så kommer inte 2000 med. Senare under 2000-talet när man vill köra år 2001 och anger bokföringsår > 00 så kommer allt utom år 2000 med alltså hela 1900-talet. I-deskriptorer och variabler som är årtal bör alltså ändras till att vara 4-ställiga om de används till urval eller som sorteringsnycklar.

 

För det tredje kan man få problem att ange vilket sekel det gäller när man matar in ett datum om det bara finns 2 årtalssiffror. Om man använt UniVerse datumkonvertering slipper man problem, år 30-99 tolkas nämligen som nittonhundratalet och 00-29 som 20-hundratalet.

Dessutom är det vanligen så att datumfält är åtta tecken långa för att kunna presentera datum prydligt med avskiljare ( t.ex. 96-12-13 ) och då kan man ju skriva 19181213 i fältet (som sen visas som 18-12-13).

 

Varför är dag 1 den första januari 1968?

Det påstås att Richard Pick fick igång det första PICK-systemet den dagen och att alla system i PICK-familjen ärvt detta startddatum. Säkert är att UniVerse mfl har ärvt sin dag 1 från Pick’s system, men Richard Pick hade ett bättre skäl för valet av datum. För att göra alla konverteringsrutiner så enkla som möjligt ska dag 1 vara den första januari ett skottår och samtidigt vara den första dagen i en vecka alltså en måndag. En av de dagar som uppfyller villkoren är just 1968-01-01.

 

Vad är slutsatsen ?

Man bör välja produkter som inte har problem med övergång till år 2000, till exempel UniVerse samt anlita företag som åtminstone löser de problem som är lätta att förutse redan vid utvecklingen av applikationerna. Ett sekelskifte kan väl ändå inte komma som någon överrasking ens för våra största konsultbolag?

Hur löser er programvaruleverantör problemet? Har de mage att ta betalt av dig som har underhåll på produkterna?

 

Om Ni ändå har kommit fel, kan vi hjälpa er med korrigeringar för år 2000.

 

Hur är det med nästa problem, EU-valutan ?

Klarar universe år 2000?

Ja, om man bara talat om att datumfälten är datum och inte lagrat dem som text-strängar så kommer allt att fungera lika bra efter nyår år 2000 som före. Du kan i ett urval skriva DATUM < 000101 och få med poster med DATUM på 1900-talet!

Hur är detta möjligt?

Hemligheten är att inte lagra datum som år-månad-dag utan som antal dagar efter ett bestämt datum, i vårt fall den sista december 1967.

Men behöver jag inte ange årtal med 4 siffror för att ange vilket sekel det gäller?

Jo om datumen kan spänna över långa perioder är det nödvändigt med 4 siffror. Om datumfältet är sådant att du idag skulle vara osäker på om 980301 avser 1898 eller 1998 (eller 1798 eller 2098) måste du naturligtvis ha fyra siffror ( eller absolut minimum tre) och det har du i så fall säkert redan. Två-siffriga årtal kan användas när man vet att årtalet under alla förhållande är ganska nära nutid. Det är ju inga problem att förstå att ett projekt som startar i år och beräknas färdigt 001231 inte var färdigt 19001231! I universe är ‘ganska nära nutid’ preciserad till att för datum med två-siffriga årtal så är det 2000-tal om året är mindre än 30 och 1900-tal om året är större än eller lika med 30. Det är alltså inte så att tvåsiffriga år automatiskt tolkas som 1900-tal.

Behandlar universe år 2000 som skottår?

Ja, universe tar hänsyn till både 100- och 400-årsreglerna för skottår. Alltså 2000 är skottår men 1900 och 2100 är inte skottår, precis som det ska vara.

Klarar alla universe-program år 2000?

Ja, om de överallt arbetar med datum i internformat så kan det inte bli några problem. Detta är det naturliga sättet att behandla datum i universe och det är dumt att inte använda det eftersom det inte bara undviker sekelskiftesproblemet utan också ger en rad andra fördelar. Det blir t.ex. mycket enkelt att beräkna antal dagar mellan två datum ( man tar bara skillnaden, alltså vanligt minus) eller att räkna fram en dag 20 dagar efter ett givet datum (vanligt plus). På grund av de stora fördelarna med att använda interndatum är det, vågar vi påstå, mycket sällsynt att program utvecklade i universe (eller någon annan pick-databas) inte använder interndatum. Nej, inte om de använder strängrepresentation av datum och bara har två siffror i årtal eller om de har fält som bara innehåller årtal med två siffror. Även det kan gå bra men bara så länge som inte årtalen ska jämföras med mindre än eller större än, lika-med går bra. Nej, inte heller om de använder något datum som en kod eller markering för något annat. Man skulle t.ex. kunna ha använt 991231 som kod för obegränsat framåt i tiden. Se upp med program som är konverterade till universe från någon annan miljö, kanske särskilt före detta cobol-program eftersom det i cobol var naturligt och allmänt accepterat att datum lagrades som strängar med tvåsiffriga årtal.

Universe - systemet som löste år 2000-problemet redan dag 1 !