arrow_back Hvilke problemer og løsninger har tidssoner og sommertid for Clarion TIME?

Question

Vårt depot bevarer et system med både Clarion DATE og Clarion TIME kolonne-typer.

Clarion DATE har en entydig definisjon som kan transformeres til et stanardisert datoformat, f. eks. "YYYY-MM-DD".

Men Clarion TIME kan være uavklar definisjon på mot tidssoner og sommertid,
- Hvilken tidssone ble systemet brukt i?
- Hvilken sommertid ble systemet brukt i?

Med andre ord er defninsjon og transformasjon gjenstand for tolking av hvordan verdien er lagret som en tid.

Spørsmål:
1. Hvordan håndteres dette i depot ved ordning (beskrivelse av kolonnen), bevaring og eventuell formidling av systemet?
2. Hvilke andre problemstillinger må bevaring ta hensyn til?

Comments

Dette er nok ikke et problem med Clarion Time i seg selv, men heller hvordan utvikler har valgt å lagre dato i databasen sammen med hvordan disse håndteres i logikk. Her bør man få kommunisert med utvikler for å høre i hvilke tidssone en dato blir lagret i databasen som. Om man ikke vet at 02.01.2021 00.59 er GMT+2 eller GMT, eller kanskje UTC, så er det vanskelig å avgjøre på hvilke lokal dag noe ble lagret.

---

Utfordringa med de systemene vi har funnet Clarion Date og Time i er at de alle er gamle systemer hvor det ikke lenger er en leverandør og ei heller utviklere tilgjengelig som kan forklare logikken tenkt for feltene.

På samme måte er det ofte gamle systemer som arkivskaper ikke lenger bruker aktivt og hvor de ansatte som brukte systemet ikke er tilgjengelig til å forklare bruken. Det går også kort tid fra brukere har brukt et system aktivt til at de ikke husker helt hvordan detaljene i bruk og innhold var.

Derfor blir det mye opp til arkivaren som vurderer systemet for bevaring å tolke mening og sammenheng mellom data og felter.