🚀 go-pugleaf

Philip Paeps wrote:
> In be.comp.programming Sjoerd A. Schreuder <sa_schreuder@wanadoo.nl> wrote:
>>Johan Wevers wrote:
>>>Passero <yanongena@pandora.be> wrote:
>>>
>>>>Een applicatie die we testen draait op een lokale server.
>>>
>>>Wat voor soort app? Ik kwam er laatst achter dat, in elk geval onder
>>>win2000, een command-line app (CGI) zich niks aantrekt van de locale
>>>settings. Het datum formaat heb ik dan ook maar hardcoded erin gezet
>>>i.p.v. het automatisch te doen.
>>
>>Lijkt me een goed advies om datumconversies te hardcoden.
> 
> Wat wil je precies gaan hardcoden?

Hoe je een datum overstuurt. Of je dat als string, en in welk
formaat, doet, of als seconden sinds X (time_t), of als een record
met seconden/minuten/uren/etc (struct tm), of als....

Maar bovenal: indien als string, welk formaat. Want als je
uitwisseling doet in een user-defined format, kun je er flink
veel geld om verwedden dat er ergens een gebruiker is die die
instellingen anders heeft staan. En dan werkt je programma niet meer.

Moraal van het verhaal: leg het vast. Hoe je iets overstuurt is minder
belangrijk dan dat beide kanten het op dezelfde manier doen.

>>Als je een datum naar buiten je programma moet tonen, kan dat
>>naar twee verschillende "gebruikers":
>>* Menselijke gebruikers. Hiervoor zijn de lokale instellingen.
> 
> 
> Als je je data print met ctime(3) worden die lokale instellingen ook netjes
> gerespecteerd, zoals de gebruiker verwacht.  Je kunt ook met strftime(3)
> knoeien, dan negeer je je gebruiker zijn settings.  In dat geval kan je
> misschien een format ergens hardcoden, maar het lijkt verstandiger om de
> gebruiker over zo'n dingen te laten beslissen...

Helemaal mee eens. Daarom schreef ik ook "hiervoor zijn de lokale instellingen".

>>* Andere programma's. Hiervoor specificeer je een uitwisselingsformaat.
>>   Deze specificatie is incompleet als er niet duidelijk is in welk
>>   formaat datums worden uitgewisseld.
> 
> Meer dan struct tm en time_t heb je echt niet nodig hoor.

Klopt. En in C heb je die. In diverse talen (VB/javascript/...) worden
datums echter meestal als string geserialiseerd. En dan heb je de problemen
waar we nu over spreken.

Daarnaast zijn er een boel programmeurs die er niet eens bij nadenken.
Jij en ik behoren daar duidelijk niet toe, maar ze bestaan wel. Die
mensen moeten worden aangeleerd om er wel over na te denken.

>>Aangezien het hier gaat om communicatie met een andere computer, had het
>>uitwisselingsformaat moeten vastleggen hoe een datum gerepresenteerd wordt.
> 
> Als je gewoon een time_t uitwisselt, kan je ze heel eenvoudig aan de twee
> kanten van het protocol behandelen naar wens.

Couldn't agree more. Maar ook in dat geval heb je het formaat vastgelegd.

>>Het probleem ligt dus niet bij de lokale server of een andere server, maar
>>ofwel bij de ontwerper die heeft verzuimd om vast te leggen hoe datums
>>moeten worden getransporteerd, ofwel bij de programmeur die heeft aangenomen
>>dat alle computers dezelfde instellingen als zijn eigen computer hebben.
> 
> Daar ben ik het volkomen mee eens :-)

:-)

Sjoerd