Tijden veranderen
Locale
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:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
# 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";
}
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.
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
# mm/dd/yyyy naar dd-mm-jjjj
function dmjDatum($mdj) {
$aMaandKort = ['leeg', 'jan', 'feb', 'mrt', 'apr', 'mei', 'jun',
'jul', 'aug', 'sep', 'okt', 'nov', 'dec'];
$j=substr($mdj,6,4);
$d=substr($mdj,3,2);
$m=substr($mdj,0,2); // 01..12
$maand = $aMaandKort[$m];
return "$d $maand $j";
}
function dmjDatum($mdj) {
$aMaandKort = ['leeg', 'jan', 'feb', 'mrt', 'apr', 'mei', 'jun',
'jul', 'aug', 'sep', 'okt', 'nov', 'dec'];
$j=substr($mdj,6,4);
$d=substr($mdj,3,2);
$m=substr($mdj,0,2); // 01..12
$maand = $aMaandKort[$m];
return "$d $maand $j";
}
Heb je daar wat aan?
Gewijzigd op 20/06/2017 01:10:05 door Paul Ulje
Code (php)
Daarbij heb je dan direct ook een controle op of er niet AA/13/2000 staat of een andere foute datum
De draait nu simpel weg wat elementen in een string om, waarbij je niet weet of het formaat klopt of ook maar de lengte 10 karakters is.
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.
Code (php)
1
2
3
4
5
2
3
4
5
$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');
// 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.
En nu?
:-)
Gewijzigd op 20/06/2017 01:42:09 door Paul Ulje
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.
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.
Gewijzigd op 21/06/2017 15:05:01 door Paul Ulje
Paul Ulje op 21/06/2017 14:48:04:
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.
Dus je accepteert zelf ook een ongeldige datum als input zolang daar maar een geldige datum uit af te leiden is. ;-)
Gewijzigd op 21/06/2017 15:03:40 door Ward van der Put
het is nu 21 juni.
+ 28 maakt 49 juni.
juni heeft 30 dagen dus 19 juli had het moeten zijn.
Of ik dat ook op de lagere school heb geleerd, kan ik me niet herinneren. Maar ik gebruik dat nog wel vaak.
Ik moet hier even over nadenken.
...
...
..
O, op die wijze.
Nee, ik ken het simpele algoritme om op die manier een datum te berekenen.
Dat is geen verkeerde invoer. Dat is de correcte invoer die nodig is om met dat algoritme de juiste datum te berekenen.
:-)
toch moet je niet blind uitgaan van "het komt van een jquery plugin en is dus goed".
Als je dat strikt doorvoert, zou je ook kunnen veronderstellen dat er *dus* ook geen ' of ander vervelend teken in voor kan komen.
En *dus* mag je het escapen achterwege laten.
Maar het is eenvoudig om zelf de waarden te kiezen om in te voeren in een POST request. Je hebt namelijk geen zekerheid dat een postend formulier ook werkelijk op jouw site stond.
Je stelt je kwestbaar op in zo'n geval, terwijl een controle in php niet heel moeilijk is.
Het dateert nog uit de tijd dat er geen rekenmachines, alleen telmachines, waren en rentekosten per dag werden gerekend. Negentig dagen krediet, dus de vervaldag is 90+21 juni is 111 juni is...etc.
Ik denk dat deze techniek na de Mammoetwet uit het curriculum is verdwenen.
Net als de tafel van 12 (dozijn, gros) :-)
Toevoeging op 21/06/2017 15:36:52:
@Ivo,
Blind vertrouwen zul je bij mij niet aantreffen.
Evenmin als strikte/rigide afregeling. :-) (wie mij kent schiet hier in de lach...)
Maar enig vertrouwen, vooral in onderdelen die erg veel gebruikt worden, heb ik wel.
Zo reken ik nooit op voorrang als ik van rechts kom.
Er wordt veel tegen gezondigd.
Maar ik houd niet echt rekening met de mogelijkheid dat iemand besluit links te gaan rijden.
Een mogelijk die wel degelijk voorkomt.
Kortom, ik vertrouw het veelgebruikte datumpikkertje van JQuery wel.
Evenals het gros van de PHP bibliotheek.
Maar als ik de werking niet begrijp, of als het erg ingewikkelde parameter overdrachten zijn zoals die met het doorgeven van het 'datumformat' voor een datuminterpretatie, dan word ik argwanend.
Het 'escapen' is inderdaad draak van een implementatieprobleem.
Dat de onderdelen van het PHPconglomeraat eigen eisen stellen, het doet pijn aan het brein.
Mr het moet. Vandaar die preMySQL()....
Dat van die dat postend formulier die niet om mijn webpagina staat vind ik wel intrigrerend.
Is dat mogelijk? Hoe werkt dat? (nieuwe draad?)
Ga naar een pagina op je website met een formulier.
Kijk in je browser naar de bron van de pagina. (in mijn browsers middels ctrl-U)
Sla dat op op je lokale pc. onder form.html (html, niet php)
Pas dan in die file <form action=""> aan naar <form action="http://site.nl/contact.php">
of waar het oorspronkele form ook maar naar verwees.
Dat is stap 1 (als er veel middels javacript gerommeld wordt, kan het zijn dat het niet direct werkt)
stap 2 is om van een input iets nieuws te maken.
Bijvoorbeeld
<select name="aantal">
<option value="1">1</option>
<option value="2">2</option>
</select>
En je wilt er 5 bestellen?
Voeg toe:
<select name="aantal">
<option value="1">1</option>
<option value="2">2</option>
<option value="5">5</option>
</select>
Of voeg toe:
<option value="ABC">xyz</option>
Wat nu? er staat ineens een string en geen getal....
Kan de php code daar tegen?
En wat als het "AB'C" is?
In plaats van de hele pagina kun je ook de htmlcode beperken tot alleen het formulier.
Alternatief: er zijn ook tooltjes die dat kunnen regelen.
Ik heb op mijn desktop een Advanced REST client staan.
Bedoeld om webservices te testen, maar daarmee zou je ook een ander formulier in kunnen vullen.
--
goed, er zijn manieren om te controleren of een formulier van jouw site komt. Bijvoorbeeld middels een extra token in een hidden input waarbij je bijhoudt of form recent is gedownload, evt. in combi met sessions.
Maar waar het mi. vooral om gaat: ga er niet vanuit dat je weet wat er gepost kan worden, omdat iets uit een <select> of een radiobutton oid. komt