Hi Arien. Zoals je ziet is de view genaamd bericht. De view word gebruikt als bericht voor het verzenden van een email bericht aan de eigenaar van het restaurant. Alle andere variabelen zijn goed.
Tijd om eens gestructureerd te gaan debuggen: plaats overal waar de datum een operatie ondergaat een var_dump($datum) om te controleren of $datum na die operatie de verwachte waarde, toestand of opmaak heeft.
"... De datum komt van een jQuery datepicker en heeft het volgende format mm/dd/yyyy..."
Ik lees deze discussie met verwondering. Zelf kom ik ook om in de verwarrende veelheid van mogelijkheden die PHP biedt om iets met datums te doen. Dat heb ik opgelost door een routine te schrijven die van een willekeurige datum een timestamp maakt. Dan is rekenen met de kalender makkelijk en elke uitvoer naar smaak te maken.
Maar begrijp ik het nou goed dat er een gewone, netjes gestructreerde string "mm/dd/yyyy" bijvoorbeeld "06/20/1952" geleverd wordt?
En dat er een string "20-06-1952" gewenst wordt?
Waarom dan niet een simpele weg gekozen? Iets als:
# mm/dd/yyyy naar dd-mm-jjjj
function dmjDatum($mdj) {
$j=substr($mdj,6,4);
$d=substr($mdj,3,2);
$m=substr($mdj,0,2);
return "$d-$m-$j";
}
O ja, ik zie het probleem nu pas bij de tweede lezing. Je wilt de maand als Nederlandse naam erin hebben. Dan zou ik het zoiets doen.
Ivo, de invoer komt uit een jQuery datumpikker.
Wordt dus gegenereerd door een uitermate uitgetest en veel gebruikte bibliotheekfunctie.
Die invoer is correct. Altijd. Daar kun je niet aan twijfelen. Nou ja, ik niet.
En het spijt me dat mijn tip zo simpel is. Het kan natuurlijk altijd veel geavanceerder. Maar daar ontbreekt me de PHP kennis.
Ik heb je formule even uitgeprobeerd.
Want ik wil wel leren wat het DateTime object/class allemaal vermag.
$invoer='13/20/52'; // dubbelincorrect
// die datum bestaat niet
// het jaargetal is niet vier cijfers
if($dt = DateTime::createFromFormat('m/d/Y', $invoer))
echo $dt->format('d-m-Y');
levert de uitvoer: 20-01-0053
Is dat werkelijk de bedoeling?
1. toch een datum gemaakt van een onjuiste invoer.
2. verkeerd jaargetal (niet vier cijfers) verwerkt tot onjuist jaartal.
de 20e dag van de 13 maand is de 20e dag van de maand na de 12e (dec), dus januari.
Ik geef toe, dat ik een melding verwacht had over de incorrecte datum, maar bij nader inzien doen andere datumfuncties van PHP hetzelfde.
Vergelijkbaar met de februaritelling van Jacques Plafond in het radioprogramma Ronflonflon. Omdat hij ooit een uitzending had op 2 maart is daar voor de gein 30 februari van gemaakt. En dat heeft hij maanden en maande volgehouden: (234 febr etc)
---
Waar je rekening mee moet houden: de gebruiker voert de datum in. Daar kun je een hele hoop javascript omheen zetten en velden required maken in je formulier en daarin ook afdwingen dat een gebruiker precies een emailadres invoert etc, maar je hebt nooit zekerheid dat de gebruiker zijn info ook inderdaad via die route post en dat zijn javascript ook (foutloos) werkt.
Als jij als ontwikkelaar een typfout maakt in een ander script, of om een of andere reden laadt iets niet goed: geen js.
Als iemand zelf het form post met een eigen tooltje of een eigen gebouwde pagina: geen controle.
Daarom altijd in PHP ook nog even controleren wat er aangeleverd werd en of dat voldoet aan de eisen.
Verder er vanuit gaan dat elk invoer vervuild kan zijn met ' om de database te verstoren, of <script> en andere tags om op je scherm dingen te vernaggelen.
"..een melding verwacht had over de incorrecte datum, maar bij nader inzien doen andere datumfuncties van PHP hetzelfde."
Als beginneling in PHP loop ik regelmatig tegen dit soort (in?)consequenties aan.
In deze dt-formulering is PHP zo slim om er toch een datum uit te berekenen. Knap werk, op de achtergrond, maar dat willen/verwachten 'we' helemaal niet. Een foute ingave moet geen mogelijke datum geven.
Precies daarom schrijf ik liever mijn <b>eigen</b> eenvoudige routine waarvan ik <b>zeker weet wat het doet</b>, als ik zeker weet wat ik erin stop. Dat scheelt tijd en vooral ergernis.
Mijn (Pascal) manier om invoer te verwerken is ook nogal eenvoudig.
<b>EERST</b> controleren of de data/invoer/(uitvoer) aan alle vereisten voldoet, DAN pas doorgeven aan 'het programma'. (Eigen PHP functies als prePHP(), preMySql() en preHTML() e.d.)
Dus hoeft het programma nergens te testen of de invoer wel deugd. Want ja, die deugd. Zeker weten.
Hetzelfde geldt op object- en functie-niveau: EERST zeker weten dat de invoer correct wordt aangeleverd. EERST zeker weten dat de uitvoer correct wordt afgeleverd. Dat laatste blijkt in het geval van PHP zelfstudie te vereisen...
Anderen die van de routines gebruikmaken zijn vooraf geïnstrueerd (documentatie) welke invoer verwacht wordt. De rest is aan hen/hun.
In het geval van het datumpikkertje, ik heb ook ooit een JQuery datumpikkertje gebruikt, vermoedelijk dezelfde, is het simpel. Daar komt geen mensenhand aan te pas. JQuery plakt de dag, de maand en het jaar bij elkaar en de uitvoer string voldoet aan de datumeis. Zeker weten. Geen controle nodig. Overigens is dat ook het antwoord dat ik geef als mensen me vragen waarom ze ergens bij het ingeven van een datum in een webformulier dat alleen via pulldownlijstjes kunnen doen. Nou, dat is om te voorkomen dat er foute datums (jaja...) worden ingevoerd.
Dat van Ronflonflon kende ik niet, maar het is wel de standaard manier om uit het hoofd datums (ja...) te berekenen Over 60 dagen is het 81 juni, dat is 81-30 is 51 juli, dat is 20 augustus. Dat leerden wij vroeger gewoon op de lagere school.
