🚀 go-pugleaf

Passero wrote:

> Een applicatie die we testen draait op een lokale server. Blijkbaar als 
> we de app overzetten van lokaal naar live dan draait hij alle data om:
> dd/mm/yyyy => mm/dd/yyyy De landinstellingen van de servers komen 
> nochtans overeen. Ze staan beide op nederlands. Het formaat dat we 
> willen gebruiken is dd/mm/yyyy maar als ze niet op beide servers gelijk 
> staan dan geeft dat problemen bij het overzetten. Welke instelling zou 
> het nog kunnen zijn?

Het heeft iets handigs om te zeggen welke OS + versie.
Daarom kijk ik gewoon even op mijn w98 client.
start->settings->control panel->regional settings.
Op de date tab kun je het datum formaat instellen.

-- 
Wil je ook niet voor muisklikken gaan betalen?
Stem dan tegen de Europesegrondwet.

pim. ReplyTo: nospam4me [at] schaeffer.tk


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.

-- 
ir. J.C.A. Wevers         //  Physics and science fiction site:
johanw@vulcan.xs4all.nl   //  http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

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.

Als je een datum naar buiten je programma moet tonen, kan dat
naar twee verschillende "gebruikers":
* Menselijke gebruikers. 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.

Aangezien het hier gaat om communicatie met een andere computer,
had het uitwisselingsformaat moeten vastleggen hoe een datum
gerepresenteerd wordt.

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.

Sjoerd

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?

> 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...

> * 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.

> 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.

> 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 :-)

 - Philip

-- 
Philip Paeps                              Please don't email any replies
philip@paeps.cx                               I follow the newsgroup.

  Laugh and the world laughs with you. cry and ...
  you have to blow your nose.

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