[PHP] Datum functie geeft rare uitkomst *

[Verwijderd]

Geachte lezer,

Voor meerdere dingen bij mij website laat ik de datum in de database opslaan met: date("jmy");
Dit geeft de volgende output voor vandaag: 20507

Als ik deze 'stamp' dan door mijn functie haal, krijg ik de volgende output terug: 2 mei 2007

Helaas werkt het niet bij de maanden 8 en 9, en dat vind ik nogal raar. Ik kan de oorzaak hier niet van vinden, want als ik bijvoorbeeld 120807 invul, krijg ik "12 08 2007" terug, en dus niet 12 augustus 2007.

PHP:

    function datum($stamp)
    {
        if(strlen($stamp)==6)
        {
            $dag   = substr($stamp, 0, 2);
            $maand = substr($stamp, 2, 2);
            $jaar = "20".substr($stamp, 4);
        }
        else
        {
            $dag   = substr($stamp, 0, 1);
            $maand = substr($stamp, 1, 2);
            $jaar = "20".substr($stamp, 3);
        }
        if(    $maand == 01){$maand = "januari";    }
        elseif($maand == 02){$maand = "februari";   }
        elseif($maand == 03){$maand = "maart";      }
        elseif($maand == 04){$maand = "april";      }
        elseif($maand == 05){$maand = "mei";        }
        elseif($maand == 06){$maand = "juni";       }
        elseif($maand == 07){$maand = "juli";       }
        elseif($maand == 08){$maand = "augustus";   }
        elseif($maand == 09){$maand = "september";  }
        elseif($maand == 10){$maand = "oktober";    }
        elseif($maand == 11){$maand = "november";   }
        elseif($maand == 12){$maand = "december";   }

        return $dag . " " .$maand. " " .$jaar;  
    }

Alvast bedankt

[Gonadan]

Kijk sowieso even naar de PHP date functies.
Je bent nu het wiel opnieuw aan het uitvinden.

Waarom het precies bij 8 en 9 fout gaat weet ik niet.
Maar je gebruikt nu een getal met voorloopnul als integer, dat kan je dan beter als string doen.

Wat geeft 120507?

[ Voor 48% gewijzigd door Gonadan op 02-05-2007 14:32 ]

[Verwijderd]

Gewoon int(11) in db opslaan met php time() functie doe ik altijd.
En dan met date functie terughalen.

[sQuarecoW]

Als je de standaardmanier van opslaan aanhoudt, dan weet PHP welke tekens wat voorstellen. Dan hoef je dus zelf niet met substr() aan de gang.

Ergo: zoals Gonadan al zegt: verdiep je even wat meer in de tijd/datum functies op php.net..

[Verwijderd]

120507 geeft gewoon 12 mei 2007 terug

[Sabbi]

Volgens mij schuilt het probleem erin dat je getallen met tekst aan het vergelijken bent en vice versa.

je vergelijkt hier

code:

elseif($maand == 08){$maand = "augustus";

"08" met het getal 8 dat is niet hetzelfde, dus je if is FALSE.

Verder zou ik gewoon lekker de tijdsfuncties van php gebruiken als de rest vd mensen.

[Jimbolino]

als je zoiets wil laten werken, zou ik ook consequent zijn met het aantal nullen dat je gebruikt.

eerst heb je het over 20507, daarna over 120807

[Verwijderd]

Sabbi schreef op woensdag 02 mei 2007 @ 14:36:
"08" met het getal 8 dat is niet hetzelfde, dus je if is FALSE.

True, maar gek genoeg zou 05 dan toch ook fout moeten gaan lijkt me. Maargoed, de discussie is in principe niet nuttig.

Jimbolino schreef op woensdag 02 mei 2007 @ 14:39:
als je zoiets wil laten werken, zou ik ook consequent zijn met het aantal nullen dat je gebruikt.

eerst heb je het over 20507, daarna over 120807

Hoe vreemd de constructie ook is, hij checkt het wel goed. Want hij checkt eerst het aantal chars, en afhankelijk daarvan bepaalt hij de substr voor de dag. De maand heeft altijd een 0 ervoor, de dag niet.

[ Voor 50% gewijzigd door Verwijderd op 02-05-2007 14:41 ]

[Crayne]

Lama. Hele grote lama.

[ Voor 95% gewijzigd door Crayne op 02-05-2007 14:44 . Reden: Spuit 11 ]

[zwippie]

Bij 1 oktober gaat het volgens mij ook fout, daar maakt ie 11005 van wat 5 karakters is zodat het 11-0-2005 wordt.Foutje

Verder geeft de PHP manual nog de tip:

To format dates in other languages, you should use the setlocale() and strftime() functions instead of date().

[Verwijderd]

Oke, bedankt voor de antwoorden mensen, nu ben ik eruit

[Sabbi]

Verwijderd schreef op woensdag 02 mei 2007 @ 14:39:
[...]
True, maar gek genoeg zou 05 dan toch ook fout moeten gaan lijkt me. Maargoed, de discussie is in principe niet nuttig.
[...]

Het punt is dat als je php het laat uitzoeken dat er dan rare dingen gebeuren. Als je gewoon netjes met "08" of met "05" compared dan werkt het wel, is nl allebei string.

[Rockafello]

misschien aardig om te vertellen wat je nou veranderd hebt, zodat andere mensen er ook wat aan hebben

[Verwijderd]

Sabbi schreef op woensdag 02 mei 2007 @ 14:47:
[...]


Het punt is dat als je php het laat uitzoeken dat er dan rare dingen gebeuren. Als je gewoon netjes met "08" of met "05" compared dan werkt het wel, is nl allebei string.

Ik was het niet met je oneens.

[Voutloos]

Verwijderd schreef op woensdag 02 mei 2007 @ 14:39:
[...]
True, maar gek genoeg zou 05 dan toch ook fout moeten gaan lijkt me. Maargoed, de discussie is in principe niet nuttig.

Wel nuttig, want dit is imo basiskennis.
http://nl2.php.net/manual/en/language.types.integer.php

PHP:

$a = 1234; // decimal number
$a = -123; // a negative number
$a = 0123; // octal number (equivalent to 83 decimal)
$a = 0x1A; // hexadecimal number (equivalent to 26 decimal)

Als je dus zonder quotes met voorloopnullen aan het stunten ben, ben je dus bezig met octale notatie ipv decimale notatie. Voor getallen 0 t/m 7 maakt dit niet uit, vandaar dat die maanden goed gingen.

[sam.vimes]

Getallen die met het cijfer 0 beginnen, zijn octaal. In principe zou je bij 08 en 09 een foutmelding van php moeten krijgen, omdat dat ongeldige octale getallen zijn. Kennelijk gebeurt er in plaats daarvan iets ongedefinieerds.

Verder ben ik het eens met alle posters die adviseren om de standaard datumfuncties van php te gebruiken.

[Gonadan]

# php -r "echo 08;"
0
# php -r "echo 07;"
7

Ofwel: hij krijgt het inderdaad niet voor elkaar om 08 te interpreteren en maakt er dan maar 0 van.

[Raynman]

Als je het in een database opslaat, kun je ook gewoon een datumtype van die database gebruiken. Dan kun je ook nog wat rekenen in bijv. een WHERE-clause en met de juiste functie (TO_CHAR, DATE_FORMAT, ...) kun je weer de gewenste uitvoer krijgen.

[Flapp]

is het niet handiger om inplaats van een if constructie, een case constructie te gebruiken?

[Gonadan]

Flapietoetoe schreef op woensdag 02 mei 2007 @ 15:41:
is het niet handiger om inplaats van een if constructie, een case constructie te gebruiken?

Of een array, en dan gewoon het maandnummer als key gebruiken.

Maar uiteindelijk kan PHP het gewoon zelf als je locale op NL staat.

[--Erik--]

Waarom maak je geen gebruik van de DATE(TIME) functie in je database?

Je wil een datum wegschrijven, dan kies je toch voor het type DATE?

[Verwijderd]

PHP:

function datum($stamp){
    $dag   = substr($stamp, 0, 2); 
    $maand = substr($stamp, 2, 2); 
    $jaar = "20".substr($stamp, 4); 
    
    setlocale(LC_ALL, 'nl_NL');
    return strftime("%d %B %G",mktime(0, 0, 0, $maand, $dag, $jaar));
}

[GlowMouse]

Verwijderd schreef op woensdag 02 mei 2007 @ 16:34:

PHP:

function datum($stamp){
    $dag   = substr($stamp, 0, 2); 
    $maand = substr($stamp, 2, 2); 
    $jaar = "20".substr($stamp, 4); 
    
    setlocale(LC_ALL, 'nl_NL');
    return strftime("%d %B %G",mktime(0, 0, 0, $maand, $dag, $jaar));
}

Voor cross-platform kun je beter setlocale(LC_ALL, 'nld_nld', 'nl_NL'); gebruiken. Tussen Windows en *nix kun je anders volgens mij al niet zomaar switchen. Setlocale gaat alles één voor één af, dus je vermeldt niet snel iets teveel.
Vreemd trouwens om te zien dat je " en ' door elkaar gebruikt

[Verwijderd]

Ik moet zeggen dat ik in single- en doublequotes normaal zeer consistent ben, dit was een ranzig copy/paste van PHP.net. Excuses

[ Voor 3% gewijzigd door Verwijderd op 02-05-2007 17:06 ]

[Gonadan]

GlowMouse schreef op woensdag 02 mei 2007 @ 17:03:
Vreemd trouwens om te zien dat je zowel " als ' door elkaar gebruikt

Niet zo boeiend, of je moet aan micro-optimalisatie willen doen.

Jammer trouwens dat de dag geen voorloop 0 heeft, anders kon je mooi strptime() gebruiken.

En misschien is het ook beter om in plaats van LC_ALL te beginnen met LC_TIME, want daar gaat het uiteindelijk om.
Het is trouwens sowieso gevaarlijk om midden in je code met locales te gaan spelen, persoonlijk ben ik er voor om die op één plaats één keer goed te zetten en er dan niet meer aan te komen.

[ Voor 31% gewijzigd door Gonadan op 02-05-2007 17:08 ]

[GlowMouse]

Gonadan schreef op woensdag 02 mei 2007 @ 17:07:
[...]

Niet zo boeiend, of je moet aan micro-optimalisatie willen doen.

Jammer trouwens dat de dag geen voorloop 0 heeft, anders kon je mooi strptime() gebruiken.

Niet boeiend om mee te optimaliseren, wel boeiend om consistent mee om te springen in je code.
In plaats van zulke noodoplossingen kan TS beter de output van mktime al in de database hebben staan. Dat scheelt niet alleen 1 of 2 bytes met zijn huidige opzet, ook is er een stuk handiger mee te werken.

Het is trouwens sowieso gevaarlijk om midden in je code met locales te gaan spelen, persoonlijk ben ik er voor om die op één plaats één keer goed te zetten en er dan niet meer aan te komen.

Wanneer je het maar één keer nodig hebt, wil ik dat betwijfelen. Terwijl het script wordt uitgevoerd, kan de locale namelijk door een ander script beïnvloed worden:

The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server api like IIS or Apache on Windows you may experience sudden changes of locale settings while a script is running although the script itself never called setlocale() itself. This happens due to other scripts running in different threads of the same process at the same time changing the processwide locale using setlocale().

[Gonadan]

GlowMouse schreef op woensdag 02 mei 2007 @ 17:12:
Niet boeiend om mee te optimaliseren, wel boeiend om consistent mee om te springen in je code.
In plaats van zulke noodoplossingen kan TS beter de output van mktime al in de database hebben staan. Dat scheelt niet alleen 1 of 2 bytes met zijn huidige opzet, ook is er een stuk handiger mee te werken.

Dat de oplossing van de TS niet al te best is waren we het al over eens.
Er bestaan niet voor niets een integer timestamps in PHP e.d. en datum velden in *SQL.

Zelf gebruik ik alleen single quotes als er niets te interpreteren valt zoals variabelen.

Wanneer je het maar één keer nodig hebt, wil ik dat betwijfelen. Terwijl het script wordt uitgevoerd, kan de locale namelijk door een ander script beïnvloed worden:

Ah dat wist ik dan weer niet.
Dus dan betekent dat er elke keer als je een functie gebruikt die afhankelijk is van een locale je voor de zekerheid even de locale moet wijzigen?
En met erg veel pech kan het zelfs nog gebeuren dat er tussen die twee aanroepen een verandering van locale optreedt door een ander script? Kan ik moeilijk geloven eigenlijk. Maar het zal wel.

[GlowMouse]

Gonadan schreef op woensdag 02 mei 2007 @ 17:17:
[...]
Ah dat wist ik dan weer niet.
Dus dan betekent dat er elke keer als je een functie gebruikt die afhankelijk is van een locale je voor de zekerheid even de locale moet wijzigen?
En met erg veel pech kan het zelfs nog gebeuren dat er tussen die twee aanroepen een verandering van locale optreedt door een ander script? Kan ik moeilijk geloven eigenlijk. Maar het zal wel.

Het probleem heb ik eens gehad met het maken van een nieuwsbrief. Het genereren kostte ongeveer een halve seconde; en af en toe kwam het voor dat in die tijd de locale gewijzigd was.
Het beste zou een eigen strftime-functie zijn die eerst de locale goedzet en daarna de echte strftime aanroept. Daartussen zit zo weinig tijd, dat je het risico dat je dan nog loopt voor lief moet nemen. Je code blijft met zo'n functie redelijk schoon.