Europees input type 'date' vertaalt naar yyyy-mm-dd in feedback form. Hoe verander je de output?
Het zou toch vrij simpel moeten zijn lijkt mij. Kom er toch niet uit.
Ik vraag niet om een 'quick fix', maar wil wel graag begrijpen waarom de datum zowiezo veranderd van dd-mm-yyyy naar yyyy-mm-dd en hoe dat op te lossen.
https://stackoverflow.com/questions/2487921/convert-date-format-yyyy-mm-dd-dd-mm-yyyy
Zag er dit (plus wat toevoegingen) :
Een datum wordt gewoon in de meeste (of alle?) talen en programma's opgeslagen als een geheel getal. Het UNIX timestamp telt bijvoorbeeld de secondes vanaf 01-01-1970 0:00:00. Dit biedt twee voordelen:
a) de computer kan zonder vertaalslag direct gaan rekenen met deze getallen. (bijv. de maand berekenen maar ook het verschil in dagen berekenen tussen twee getallen)
b) het neemt minder geheugenruimte in. (32 bits)
>> Zag er dit (plus wat toevoegingen)
Dat kan korter.
Code (php)
Frank Nietbelangrijk op 13/06/2017 21:53:34:
a) de computer kan zonder vertaalslag direct gaan rekenen met deze getallen. (bijv. de maand berekenen maar ook het verschil in dagen berekenen tussen twee getallen)
Mogelijk bedoel je hier dat yyyymmdd lexicografisch (alfabetisch) geordend is? Het gewicht jaar "weegt" zwaarder dan maand wat op zijn beurt zwaarder weegt dan dag van de maand. Omdat de yyyymmdd tekststring op een zinnige manier is geordend (aflopende volgorde van gewicht) kun je hier ook alfabetische tekstvergelijkingen mee doen die hout snijden uit oogpunt van tijd (bijvoorbeeld '2017-07-01' valt na '2017-06-30' en tevens geldt '2017-07-01' > '2017-06-30'). Met andere formaten kun je dat niet (of niet makkelijk) doen.
Als je overigens niet wilt dat iemand de vrijheid heeft om iets op een bepaalde manier in te vullen, geef deze vrijheid dan ook niet :p. Maak of gebruik van dropdowns voor dag, maand of jaar of maak gebruik van een datepicker ofzo. Neemt de kans haast in het geheel weg dat een datum in het verkeerde formaat wordt aangeleverd omdat je met voorgaande genoemde manieren zelf voorschrijft hoe dit formaat zou moeten zijn.
Firefox wad het volgens mij die 31-12-2017 doorgaf en Chrome draaide hem om.
Frank Nietbelangrijk op 13/06/2017 21:53:34:
Een datum wordt gewoon in de meeste (of alle?) talen en programma's opgeslagen als een geheel getal. Het UNIX timestamp telt bijvoorbeeld de secondes vanaf 01-01-1970 0:00:00. Dit biedt twee voordelen:
b) het neemt minder geheugenruimte in. (32 bits)
b) het neemt minder geheugenruimte in. (32 bits)
Die 32-bits integer loopt ergens in het begin van 2038 vol, en dan zijn de rapen gaar. En iemand die denkt dat dat geen probleem is omdat dat nog 20 jaar duurt, heeft niets geleerd van Y2K. Overigens kun je er nu ook al last van hebben. Probeer bijvoorbeeld maar eens uit te rekenen hoeveel hypotheekrente je over 25 jaar moet betalen.
Elke zichzelf respecterende programmeertaal zal een timestamp dus niet meer opslaan in een 32-bits integer, maar in plaats daarvan een 64-bits integer gebruiken. Probeer het volgende maar eens (60-bits integer):
PHP rekent dit netjes om naar 13 mei 36534630048. Oftewel: intern wordt gebruik gemaakt van een 64-bits integer. Ik kan het dan ook niet echt verstandig noemen om een timestamp in een 32-bits integer op te slaan. In goed Engels heet dat: "setting yourself up fo failure."
Wanneer je het hebt over runtime geheugengebruik, gaat je argument "neemt minder ruimte in" dus niet op. En hoe zit dat bij MySQL? Een BIGINT gebruikt 8 bytes aan storage space, een DATETIME 5 en een DATE zelfs maar 3 bytes.
Het heeft dus zo zijn voordelen om de datum in een DATETIME of DATE op te slaan. Niet alleen gebruikt dat minder ruimte, ook is het leesbaar voor mensen, wat bijvoorbeeld debuggen een stuk fijner maakt.