Hoe in <input type="date"> een bestaand datumveld weegeven ?

Status
Niet open voor verdere reacties.

leifoet

Gebruiker
Lid geworden
7 okt 2007
Berichten
326
Nieuwe datum ingeven en opslaan met <input type="date"> werkt.
Gewoon die gesavede datum terug opvragen lukt ook.
Maar die datum terug opvragen met 'value' in de <input type=...> code hierna lukt (nog) niet.

Code:
<input type="date" name="levdag" placeholder="yyyy-mm-dd" value="<%=rs("Levdatum")%>"
(<%= betekent in PHP echo levdatum - heb ergens eenzelfde value code in PHP als voorbeeld gezien)

Ik heb begrepen dat de datum in dit inputtype moet beantwoorden aan het formaat YYYY-MM-DD

Heb dit geprobeerd te verkrijgen met
LCID-code te plaatsen op 1033 (USA) - niet OK => geeft MM/DD/YYYY
In de Access database heb ik de veldnotatie veranderd in YYYY-MM-DD => betreffende datums in het tabelveld zijn gewijzigd (van DD/MM/JJJJ) naar YYY/MM/DD maar de 'doorstroom' naar <input type=...> blijft uit.

Probleem blijft dus : waar (in de database én/of in de code) en hoe transformeer ik een Europees datumformaat (DD/MM/JJJJ) naar YYYY/MM/DD ?
Dank voor tips.
 
Laatst bewerkt:
<%= betekent in PHP echo levdatum
Dit is de notatie in php
Code:
<?= $Levdatum ?>

De code die je geeft is asp.net
Code:
<%=rs("Levdatum")%>

waar (in de database én/of in de code) en hoe transformeer ik een Europees datumformaat (DD/MM/JJJJ) naar YYYY/MM/DD
Dit hangt er vanaf. Wat is het type van DD/MM/JJJJ ? Is dit een string of getal of unix timestamp of iets anders?
 
Laatst bewerkt:
Hoe sla je het in de database op? In welk formaat? En welk datatype?
 
Een datum/tijd in Access is een getal dat telt vanaf het jaar 1900 (in db als 8 bytes). Je kan met de veldnotatie de weergave binnen Access anders weergeven. Het aanpassen van de datumnotatie buiten Access zal je in ASP moeten doen denk ik.

Zie dit voorbeeld hoe de <input type="date"> werkt.
 
Paar elementen gecheckt
- opslag in Access-tabel => Gegevenstype : Datum/tijd /// Notatie (manueel gewijzigd in) : yyyy/mm/dd /// Invoermasker (manueel gewijzigd in) : 0000/00/00;0
- datum vandaag als test in tabel opgeslagen (met input type=date) => zichtbaar in de tabel als 2021/03/27 => wordt dus wel gesaved als YYYY/MM/DD (=> input date werkt dus correct)
- een testopvraging als <%=("hallo")&" "&rs("Levdatum")%> geeft : hallo 3/27/2021 (met LCID=1033) => verwacht : 2021/03/27
- de input type=date toont (in het tekstbalkje) : dd/mm/jjjj gevolgd door het typisch kalender-vierkantje => gehoopt op 2021/03/27 met ernaast het kalendervierkantje (om eventueel de datum te kunnen aanpassen) - helaas werkt dit 'feedbackmoment' in mijn input date nog niet ;-(

Dank voor tips om dit alsnog aan de praat te krijgen.
 
Laatst bewerkt:
Intern in Access wordt een datum/tijd veld in de tabel altijd hetzelfde opgeslagen, daar heb je geen invloed op. Wijzigen van 'Notatie' en/of 'Invoermasker' bepaalt alleen hoe je het wilt zien, het bepaalt dus niet hoe het is/wordt opgeslagen.

Dat de datum 2021/03/27 op deze manier wordt getoond komt omdat je de notatie op yyyy/mm/dd hebt staan. In werkelijkheid is het niet zo in de tabel opgeslagen. In het kort: geen invloed hoe het is/wordt opgeslagen, wel invloed hoe het binnen Access wordt getoond.

Je zal de volgende ASP moeten aanpassen om de datum omgekeerd te tonen.
Code:
<%=("hallo")&" "&rs("Levdatum")%>

Ik ken ASP niet maar in PHP zou het zoiets zijn (maak van dd/mm/yyyy een array en lees die omgekeerd uit). Dit zal je zelf moeten omzetten in ASP (want ASP en PHP zijn 2 verschillende dingen).
Code:
<?php
$dmy = explode('/', $rs["Levdatum"]);
echo $dmy[2].'/'.$dmy[1].'/'.$dmy[0];
?>
 
Laatst bewerkt:
Ik heb even gegoogle'd, het hangt er misschien vanaf of je ASP-Classic of ASP.Net gebruikt.
Dit lijkt erop maar nogmaals, ik ken ASP niet
Code:
<% 
Dim dmy
dmy = Split(rs("Levdatum"), "/")
Response.Write(dmy[2] & "/" & dmy[1] & "/" & dmy[0])
%>
 
Met deze value-code lukt de weergave van het tabelveld in "Input type=date".
Code:
value="<%=(CurrentYear&"-"&CurrentMonth&"-"&CurrentDay)%>"
Enkel de(ze) code bepaalt de weergave - de opslagformat is hier inderdaad niet bepalend.
Dank bron voor de aanzet in de goede richting.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan