date van D-M-Y to Y-M-D

  • Beste leden,
    Ik zit met een klein probleem.
    De database slaat alles op als YYYY-MM-DD
    Maar ik wil als ik in een input 30-04-1992 invoer,
    dat hij het opslaat in de database als 1992-04-30
    Ik heb gegoogled, hier op het forum gezocht, maar kom er maar niet uit.
    Ik hoop dat me uitleg duidelijk genoeg is en dat jullie me kunnen helpen.
    Mvg. Jayson

  • Dit was letterlijk (met je titel) de eerste stackoverflow die ik tegen kwam:


    Code
    $var = "30-04-1992";
    echo date("Y-m-d", strtotime($var) );


    Var is dan je $_POST['iets'] en de echo is je input die je in de database wil opslaan. Dus in plaats van echo doe je $db_date of iets dergelijks:



    Code
    $db_date = date("Y-m-d", strtotime($var));

    strtotime — Parse about any English textual datetime description into a Unix timestamp
    date converteert dit vervolgens naar een leesbare datum (in de volgorde zoals je zelf aangeeft).

  • de invoer ook om te converteren naar YYYY-MM-DD?

    Als ik het oorspronkelijke bericht lees is dit volgens mij ook wat de topicstarter wil.



    DATE_FORMAT()

    Hierover verschillen de meningen, maar als er iets wijzigt in het formaat voor weergave van datums zou dit inhouden dat je queries zou moeten aanpassen. Hoe je iets presenteert zou zo dicht mogelijk bij de presentatielaag geregeld moeten worden, dus bij voorkeur in code boven gepriegel in de database.

  • Als ik het oorspronkelijke bericht lees is dit volgens mij ook wat de topicstarter wil.


    Hierover verschillen de meningen, maar als er iets wijzigt in het formaat voor weergave van datums zou dit inhouden dat je queries zou moeten aanpassen. Hoe je iets presenteert zou zo dicht mogelijk bij de presentatielaag geregeld moeten worden, dus bij voorkeur in code boven gepriegel in de database.

    Dan kan je er ook een configuratie-optie van maken. Dan hoef je geen queries aan te passen ;)

  • Dan kan je er ook een configuratie-optie van maken. Dan hoef je geen queries aan te passen

    Precies, en dan pas je dat formaat toe a.d.h.v. een PHP-functie, en niet in een placeholder in je queries, zodat het niet mogelijk is dat het foutief wijzigen van deze config variabele complete queries breekt en/of je site lamlegt.


    Als je dit wel zou doen - hoe zou je dit dan op security-gebied netjes regelen? Dan zou de validatie van de format-string wel heel erg streng moeten zijn. Escapen van deze format-string wordt wellicht ook problematisch als deze karakters bevat die binnen SQL betekenis hebben.


    Als je dit gewoon in PHP regelt is de impact ook veel beperkter als het format fout is, en heb je tevens voorgenoemde beslommeringen niet.

  • In het ergste geval een E_WARNING of E_STRICT melding, in het minst erge geval wordt false geretourneerd. Dus wat merkt een gebruiker hiervan, wellicht geen datum op het scherm? Dat kan onhandig zijn, maar dan ligt tenminste niet je hele pagina in duigen.


    Je moet ook gewoon kijken naar de impact van een ontwerpbeslissing. Een constructie waarbij rechtstreeks queries gemanipuleerd worden en dus over tijd anders kunnen gaan werken... I don't know man... Voor de goede orde zou je dan ook alle queries moeten nalopen waarin deze constructie wordt gebruikt wanneer deze opzet verandert, om het maar niet te hebben over gevallen waarbij dit dan ook gebruikt wordt om records te filteren en te sorteren (dat is dan natuurlijk slecht ontwerp van de query zelf uiteraard, maar als het kan gebeuren dan gebeurt het) *brrrr*.


    Nope, houd functionaliteit die bepaalt hoe iets er uitrolt op het scherm maar lekker ver weg van je database. YYYY-MM-DD werkt prima in een database. Geen enkele reden om daar al vast te leggen hoe iets er uit komt te zien. Haal het eruit zoals het er in zit.


    Een ander puntje voor @Jayszon010: voor datums is dat dan niet direct zo interessant, maar als er ook tijden aan komen te hangen: zorg dan ook dat alles in één tijdszone wordt vastgelegd, bij voorkeur UTC. Dit maakt het omrekenen van DATETIMEs naar andere tijdszones een stuk makkelijker, je hebt dan immers altijd hetzelfde uitgangspunt.


    Dit is in zekere zin een "nadeel" van DATE en DATETIME, dit zegt je niets over de tijdszone waar dit betrekking op heeft.

Participate now!

Heb je nog geen account? Registreer je nu en word deel van onze community!