I datasystem världen över kommer det att ske dramatiska fel när sekelskiftet inträffar. De datasystem som inte är ordentligt förberedda kommer att sluta fungera.

Problemens orsak är naturligtvis att man i grunden har valt två siffror för lite för att ange datum. I stället för att skriva 19960101 för första jan 1996 har man använt en förkortad version: 960101. När denna korta version passerar år 2000 kommer motsvarande datum att läsas 000101 eller kanske t o m med 101.

I grunden är inte problemet vad man ser av datumangivelsen, utan vad som lagras och vad som bearbetas. Antagligen kommer man även efter sekelskiftet att beteckna datum utan inledande siffror för århundrade.

Vårt mål

Vårt mål är att göra programvaran sekelskiftessäker enligt IT-Kommissionens definition.

IT-Kommissionen har följande definition för sekelskiftessäker:

Med sekelskiftessäker menas att produkten, när den används såväl före som skälig tid efter sekelskiftet enligt produktdokumentationen, kan med bibehållen funktionalitet lagra, bearbeta, lämna och ta emot datum- och tidsangivelser för såväl 1900-talet som 2000-talet.

Det innebär

• att sekelskiftet inte ska orsaka driftsstörning för produkten
• att produkten hanterar år 2000 som skottår.

Vad behöver vi göra?

• Kontroll av inlagt datum
  Normalt sker en rimlighetskontroll av ett inslaget datum. Denna kontroll accepterar inte datum av typen "000101" utan kräver t ex att den ska vara större än 960000.
  Detta hanteras genom en ändring i kontrollen. I vårt fall kommer kontroll att månad och dag är korrekta att läggas in.
• Jämförelse mellan två datum
  Om datum 990101 och 000101 jämförs så kommer programmet att betrakta det första som större.
  För att hantera detta problem måste datum hanteras med 8 siffror. Jämförelsen ska ske mellan 19990101 och 20000101.
• Redovisningsperioder
  I redovisningen hanteras periodisering med hjälp av år och månad.
  Här måste år hanteras med fyra siffror.
• Sorteringsordning via datum
  Även här måste datum hanteras med 8 siffror.
• Leveranstid
  Leveranstiden i adMix anges med t ex 9845.1 vilket motsvarar dag 1 (måndag) i vecka 45 år 2015. Inslag av leveranstid kan även göras i form av ett datum. I detta fall omvandlas det till ÅÅVV.D.
  Hantering av detta hanteras från fall till fall. Ofta räcker det med att lägga till två siffror för århundrade innnan de används. I andra fall måste lagringen ske med två siffror till.
• Konvertering av databas
  För nuvarande kunder kommer konverteringsrutiner att distribueras som en del av normala programrevideringar. Dessa omvandlar successivt adMix databas för problemfri körning under nästa sekel.
• Presentation av datum
  Ännu verkar det inte vara klart hur datum ska presenteras efter sekelskiftet. Vi avvaktar på denna punkt och koncentrerar oss på programvarans funktion.

Hur långt har vi kommit?

Leveranstider i adMix är det som sträcker sig längst fram i tiden. Leveranstider finns i de flertalet moduler och är nu helt klart. Vår kalenderhantering klarar också sekelskiftet.

Sekelskiftessäkra moduler

Hantering av datum och perioder hanteras per modul.

I följande tabell visas de moduler som är klara överst. Vi kommer successivt att flytta upp modulerna alltefterssom de blir klara.

Vi räknar med att vara helt klara sommaren 2015.

Modulnamn		Klart datum	Kommentar
Basprogram	bas	1997-12-05
Offerter	off	1997-12-10
Rapportgeneratorer	rpg	1997-12-19
Kassarutiner	knt	2015-01-27
Statistik	fsg	2015-01-28
Standardrutiner	std	2015-01-29
Order	ord	2015-02-19
Kundreskontra	krk	2015-02-25
Lager	lgr	2015-03-05
EDI	edi	2015-05-02
Registervård	rgv	2015-06-16
Lön	lon	2015-07-03
Leverantörsreskontra	lrk	2015-07-03
Inventarieredovisning	inv	2015-07-03
Redovisning	bok	2015-07-07
Marknadsanalys	adr	2015-07-07
Förkalkyl	fkl	1999-03-01
Fönstersökning	inf	1999-03-01
Tids- & uppdragsredovisning	tur	1999-06-01

Denna sida senast ändrad 991005 Copyright © 1999 Elektrondata AB