De nachtmerrie genaamd datum

 
02 maart 2011

Wanneer ik denk aan een datum dan denk ik al snel aan een Date of een Calendar. Wanneer je dan een datum toevoegt, is de format van deze datum altijd hetzelfde. Dit is niet alleen handig, maar ook nog eens gebruikersvriendelijk.

En nu hoor ik je denken: dat is toch logisch? Dat gebruikt iedereen toch? Zou je denken ja, maar in mijn huidige project (SogyoSearch) heb ik een bron waarbij ik al op minstens zes verschillende manieren een datum terug heb gekregen! Hoe kan dat? Heel simpel, ze hebben er een String van gemaakt!

Wanneer je er een String van maakt geef je de gebruiker over het algemeen erg veel vrijheid over hoe hij of zij een datum invoert en het zal je verbazen op hoeveel verschillende manieren dat gebeurt.

Ik moest voor SogyoSearch alles sorteren op datum. Niet zo moeilijk, gewoon sorteren op datum… Maar wanneer de een “02-03-2011” heeft ingevuld, heeft een ander “03-02-2011” ingevuld. Of wat dacht je van “02/03/2011” of “02/03/11” of alleen “03/11”? Nog leuker is het wanneer iemand niks invult. Dan krijg je een lege String terug. Als je geluk hebt dan! Vandaag kreeg ik namelijk voor het eerst een datum terug die null was.

Zoiets simpels als het sorteren op datum wordt zo een verschrikkelijke nachtmerrie! Mijn advies is dan ook: check de datum!! Het is niet moeilijk. Gebruik een datepicker of maak gebruik van de Calendar API van Java, maar stop een datum nou niet in een String! Het voorkomt een hoop hoofdpijn en ergernis ;-).

Nu gaat deze post dan wel over een datum, maar er zijn meerdere voorbeelden te bedenken waarbij je liever één vaste format wilt hebben. Denk bijvoorbeeld aan een telefoonnummer of een postcode. Het is niet moeilijk, dus maak gebruik van de (vele) mogelijkheden.

Namens alle mensen die ermee moeten werken: bedankt!


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Architectuur, Development

Tags: ,


Reacties (2)

  • Dit probleem herken ik. En dan ook wanneer de data als data opgeslagen zit in de database. Het ophalen van de datum gesorteerd kan ook hele leuke problemen opleveren.

    Vooral met het probleem van de dd-mm-jjjj en mm-dd-jjjj versie.

    Een manier die ik gebruikt had om dit op te lossen was de wereld tijd te pakken. Die is alleen in het formaat jjjj-mm-dd een omgedraaide versie van de maand en dag is daar officieel niet van. Dit maakte het best gemakkelijk om de datum terug te transformeren naar het formaat waar de huidige gebruiker mee werkt.

    @peter met de punten en coma’s is redelijk op te lossen met een los vakje maken voor coma getallen. User interface helpt hier zeker bij.

    Geplaatst op 12 augustus 2011 om 0:39 Permalink

  • Peter schreef:

    Zulke problemen (localization) zijn inderdaad erg irritant.

    Volgens mij is het altijd een goed idee om data op te slaan in een custom formaat (dus datums als datum, niet als string). Het grote probleem zit hem echter in de user interface. Gebruikers vinden het toch vaak fijn om zelf iets te kunnen typen in plaats van een custom control (bijv. kalender) te gebruiken. Bij datums valt het op zich nog mee, maar wat te denken van een bedrag? Hiervoor is een “gewoon” tekstveld toch wel veel gebruiksvriendelijker dan een updown-achtige control. Je zit echter direct met de vraag: wat betekent precies een punt of een komma? Wat accepteer je, en hoe parse je het? Vooral als een systeem internationaal wordt gebruikt, is dit echt een vervelend probleem.

    En als je er niet over nadenkt, laat je dit over aan frameworks of eigenschappen van het lokale systeem of dat van de gebruiker… Want wat doet in C# bijvoorbeeld float.Parse(string) als je geen culture meegeeft? Gevaarlijk!

    De wereld had er voor ons toch wel iets eenvoudiger uitgezien als dergelijke cultuurverschillen niet bestonden…

    Geplaatst op 03 maart 2011 om 15:31 Permalink