verlaat millenium probleem

[Marc Portier]

Bart wrote:
> Heej mensen,
> 
> ben op een verlaat millenium, nu eigenlijk century probleem gestuit in
> Evolution. Als je een geboortedatum probeert in te vullen na 1970
> (door dd-mm-70) en je drukt op het pijltje dan komt er mooi 1970 te
> staan. Echter 1969 en eerder wordt 2069 en eerder.
> Nu weet ik niet echt of ik dat moet melden als een bug? Maar kan
> iemand me uitleggen waarom er voor 2 getallen wordt gekozen ipv 4. Dat
> is vragen om dit soort problemen toch?
> 

nee hoor

het is makkelijk verdedigbaar dat we als mensen jaartallen met 2 digits
aanduiden (ik schat dat de gemiddelde leeftijd van mensen ruim de 130
moet overschrijden voor we in dat gebruik gaan veranderen)

jaartallen met 2 digits worden door ons mensen dan ook logsicherwijs aan
de context gekoppeld en in het juiste eeuw-venster geplaatst

en wat we als mensen doen, daar moet de computer ons maar in volgen
(niet andersom)

het y2k probleem was nu net
1/ dat men fixed de 20ste eeuw als het enige geldige eeuwvenster aannam
en dat men bij ingang van de 21ste eeuw dus dapper alle 2digit jaren
verkeerd ging interpreteren...
2/ dat men anderzijds uit geheugen-besparings-overwegingen had gekozen
om alles ook gewoon als 2digit aanduidingen op te slaan zodat die
gegevens vroeg of laat wel moesten verkeerd geinterpreteerd worden

enfin, ik zou dit dus niet als een milenium-probleem aanduiden, en ook
zeker niet gaan pleiten om altijd alle jaren met alle beduidende digits
te moeten gaan invoeren

de meeste date-parsing modules tegenwoordig ondersteunen dus immer
2digit jaar aanduidingen en doen dat meestal op basis van een
bewegend-eeuw-venster, wat wil zeggen dat men de digits vergelijkt met
die van het *huidige* jaartal en afhankelijk van de afstand ervan (soms
-50+49, soms -75+24, soms per lustrum, ...) gaat beslissen of het
ingegeven jaartal (naar grote waarschijnlijkheid) in de komende, dan wel
de volgende 100 jaar is bedoeld.


Dus blijkt van je opmerking over te blijven dat je binnen het veld
'geboortedatum' niet echt gediend bent van het gehanteerde eeuw-venster.

En ik kan daar inkomen: voor die specifieke context weten we als mens
dat -100+0 een juister beeld zou geven, al is er natuurlijk ook iets te
zeggen voor aanstaande ouders die alvast de geplande uitgerekende datum
van de nieuwe spruit willen opnemen, dus -99+1 zou dan een werkbaar
alternatief zijn?

Anderzijds is er ook het argument van conistentie (en
programmeer-eenvoud) waarbij men voor alle datum-velden binnen een
applicatie typisch zoekt om het interpreteer-gedrag consistent te
houden. (dat is ook een argument met waarde, me dunkt)

En trouwens, wie wil er nu geboortedata bijhouden van mensen van voor
'70? Die zoeken er zelf niet naar om daaraan herinnerd te worden he :-)


ondertussen:
Aangezien je dat zelf als oplossing voorstelt denk ik dat je gewoon 4
digit-jaren kunt ingeven in die datum-velden (ook al staat er dat ook
mm-dd-yy ondersteund is) dan moet evolution niet gissen wat je bedoelt.

disclaimer:
ik heb nog van me leven geen letter evolution code van dichtbij gezien,
noch ken ik de community... Ik weet dus niet of er niet effectief iets
zou kunnen veranderen. Bovenstaande wil enkel wat meer nuance bij je
opmerking plaatsen.

groetjes,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo op outerthought.org                              mpo op apache.org