Waarom wil je het in eigen formaat opslaan?

Is het niet raadzamer om de uitvoer aan te passen met DATE_FORMAT() , en de invoer ook om te converteren naar YYYY-MM-DD?

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

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

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

Citaat van AarClay

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.

Citaat van AarClay

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.

Citaat van FangorN

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

Citaat van AarClay

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.

Kijk en daar zijn inderdaad de meningen over verdeeld.

Als iemand een fout maakt in de configuratie? So what..... Dat test je toch nooit 'live' uit?

Geen idee of de boel in PHP ook breekt?

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.