Aktuelles Datum als max in ein datums Eingabefeld
EinJungerMann
- html
- javascript
Guten Tag liebe Community,
ich wollte fragen ob ihr wisst wie ich in das max das aktuelle Datum eintragen kann ?
Meine derzeitige lösung funktoniert nicht 😕
<input
type="date" id="kaufDate" class="input" name="kaufDate" max=""
autocomplete="off" onblur="this.max=input_date()" required
/>
function input_date(){
var Heute = new Date();
var Tage = Heute.getDate();
var Monate = Heute.getMonth()+1;
var Jahre = Heute.getFullYear();
return( Tage + "." + "0" + Monate + "." + Jahre );
}
Dann schau doch mal nach, wie das MDN das vorschlägt. Insbesondere die Formatierung der Zeitangabe als ISO-Datum:
<input type="date" id="start" name="trip-start"
value="2018-07-22"
min="2018-01-01" max="2018-12-31">
Außerdem ist unklar, warum Du das nicht schon serverseitig, z.B. durch PHP machst:
<?php date_default_timezone_set('Europe/Berlin'); ?>
...
<input type="date" id="start" name="trip-start"
value="<?=date('y-m-d');?>"
min="2018-01-01" max="<?=date('y-m-d');?>">
<?=date('y-m-d');?>
<?=date('Y-m-d');?>
Außerdem ist unklar, warum Du das nicht schon serverseitig, z.B. durch PHP machst.
Frag ich mich auch. Zumal die Eingabe sowieso serverseitig geprüft werden muss. Und für die die lieber klicken als 3 Zahlen einzugeben gibs Datumsauswahldialoge.
MFG
Hallo Email,
Und für die die lieber klicken als 3 Zahlen einzugeben gibs Datumsauswahldialoge.
Genau. <input type=date>
Bis demnächst
Matthias
Hallo junger Mann,
dass im max-Attribut das Datum im ISO-Format zu speichern ist, ist Problem 1.
Problem 2 ist die 0, die Du vor den Monat setzt, das musst Du weglassen. Grund: "2019-8-31" wird akzeptiert, "2019-010-31" dagegen nicht.
Problem 3 ist, dass das Setzen von max in onblur nicht dazu führt, dass eine Eingabe jenseits des Tagesdatums abgewiesen wird. Wenn Du das möchtest, muss max bereits vor Betreten des input-Feldes gesetzt sein. Wenn Du es unbedingt mit einem Event tun willst, dann mit onfocus statt mit onblur (das focus Event wird gefeuert, wenn das Eingabefeld den Eingabefokus bekommt)
Der Vorschlag von "ISO-Datum", das Problem im PHP Script am Server zu lösen, ist sicherlich die beste Idee.
Wenn Du es aus $Gründen
unbedingt am Client machen musst, dann wäre es besser, sogenanntes unobtrusive script (unaufdringlich) zu verwenden. Notiere im <head> Bereich deiner Seite z.B. so etwas:
<script>
document.addEventListener("DOMContentLoaded", function() {
let kaufDatum = document.getElementById("kaufDatum");
if (kaufDatum)
kaufDatum.max = new Date().toISOString().substring(0,10);
});
</script>
Was ist das?
Auf diese Weise hast Du kein JavaScript in deinem HTML herumschwirren, sondern eine saubere Trennung.
Falls Du mehr als ein Eingabefeld hast, bei dem max auf das Tagesdatum gesetzt werden muss, kannst Du den gezeigten Code erweitern - darauf würde ich eingehen wenn Du mir sagst, dass Du das brauchst.
Rolf
@@Rolf B
Der Vorschlag von "ISO-Datum", das Problem im PHP Script am Server zu lösen, ist sicherlich die beste Idee.
Ist es das? S.u.
let kaufDatum = document.getElementById("kaufDatum");
const
wäre statt let
angebracht.
Wenn das auch in älteren Browsern laufen soll, müsste dafür aber var
stehen. (Gibt es Browser, die <input type="date">
unterstützen, aber nicht const
?
- das Script registriert einen Eventhandler für das DOMContentLoaded Event. Dieses Event wird gefeuert, sobald das HTML Dokument interpretiert und in das Objektmodell des Browsers (das DOM) umgewandelt ist.
Wenn man das Script nicht in den header
packt, sondern am Ende des body
einbindet, braucht man den DOMContentLoaded
-Handler nicht.
Was soll aber passieren, wenn man das Formular an einem Tag öffnet (sagen wir um 23:55), aber erst am nächsten Tag ausfüllt?
Womöglich ist es doch besser, das max
-Attribut bei jedem focus
-Event neu zu setzen:
const kaufDatum = document.getElementById("kaufDatum");
if (kaufDatum)
{
kaufDatum.addEventListener('focus', function () {
kaufDatum.max = new Date().toISOString().substring(0,10);
});
}
LLAP 🖖
Hallo Gunnar,
Gibt es Browser, die <input type="date"> unterstützen, aber nicht const?
Typischer Kandidat für eine Antwort wäre IE... Der IE kann ab Version 11 const, aber type=date kann er nicht.
Ob nun const oder let... meinetwegen. Ich nehme das nicht so genau.
Womöglich ist es doch besser, das max-Attribut bei jedem focus-Event neu zu setzen:
Oder gleich einen custom validator? Wenn du dafür ein ordentliches Beispiel hättest; ich komme damit nämlich nicht klar.
Rolf
@@Rolf B
Gibt es Browser, die <input type="date"> unterstützen, aber nicht const?
Typischer Kandidat für eine Antwort wäre IE... Der IE kann ab Version 11 const, aber type=date kann er nicht.
Das war nicht die Frage.
Ob nun const oder let... meinetwegen. Ich nehme das nicht so genau.
Wenn es egal wäre, hätte man nicht beides eingeführt.
LLAP 🖖
Hallo Gunnar
Es gibt möglicherweise Situationen, in denen die Verwendung von const
Optimierungen zulässt, die mit let
nicht möglich wären. Grundsätzlich ist aber davon auszugehen, dass heutige Ausführungsumgebungen genug Codeanalyse betreiben um in den meisten Fällen zu erkennen, ob eine deklarierte Variable wie eine Konstante behandelt werden kann oder nicht. Es würde mich daher wundern, wenn es hinsichtlich der Performanz merkliche Unterschiede gäbe.
Zwischen let
und const
wird im Wesentlichen deshalb unterschieden, weil es den Code ausdrucksstärker und damit besser lesbar macht, was im besten Fall der Programmiererin dabei hilft, Fehler zu vermeiden oder sie wenigstens schneller und leichter zu erkennen. In jedem Fall vereinfacht es das mentale Modell, dass man sich von einem Programm macht, da bestimmte Möglichkeiten nicht mehr berücksichtigt werden müssen.
let x = 4
⋮
function f(a) {
return a * x // Wert von x ist vielleicht 4
}
In einem Programm mit Funktionen, die wie in dem Beispiel oben über freie Variablen verfügen, kann ich ohne Kenntnis der gesamten Umgebung keine sicheren Aussagen darüber treffen, welcher Wert bei einem Aufruf zurückgegeben wird, wenn die Variablen wie hier mit dem Schlüsselwort let
deklariert wurden, da eine andere Funktion den Wert jederzeit verändern könnte.
const y = 2
⋮
function g(a) {
return a * y // Wert von y ist sicher 2
}
Wird const
für eine Deklaration verwendet, kann ich hingegen sicher sein, dass zur Laufzeit kein anderer Wert an den entsprechenden Bezeichner gebunden wird. Die Funktion in diesem Beispiel besitzt zwar eine freie Variable, aber sie ist dennoch referenziell transparent, da die referenzierte Variable unveränderbar ist. Das Ergebnis eines Aufrufs ist nur von dem an die Funktion übergebenen Argument abhängig. Es ist in diesem Fall also möglich, Aussagen über das Programm zu treffen, die andernfalls nicht ohne Weiteres möglich wären.[1]
Nun könnte man natürlich argumentieren, dass es bei lokalen Variablen wie in Rolfs Codebeispiel keine Rolle spielt, ob let
oder const
verwendet wird, da die Auswirkungen auf einen sehr kleinen und überschaubaren Bereich des Programms begrenzt sind. Wenn man den Abschnitt isoliert betrachtet, ist dieser Argumentation auch nicht zu widersprechen.
Ein Programm besteht aber selten nur aus einem Abschnitt und angenommen es würde sonst der Konvention gefolgt, die Absicht der erneuten Zuweisung durch die entsprechende Wahl der Schlüsselwörter const
und let
kenntlich zu machen, dann würde sich dem Leser doch die Frage stellen, warum an einer bestimmten Stelle davon kein Gebrauch gemacht wurde. Das wäre dann eine unnötige Ablenkung, die dem eigentlichen Zweck der Konvention zuwiderliefe.
Ich stimme dir also zu, dass es sinnvoll ist, auch in solchen Fällen diejenige Variante zu wählen, welche die Absichten des Autors am besten verdeutlicht.
Viele Grüße,
Orlok
Allgemein gilt dies aber nur unter der Einschränkung, dass mit der freien Variable wie in dem Beispiel ein skalarer Wert verknüpft ist, da const
lediglich dafür sorgt, dass die Bindung zwischen Wert und Bezeichner unveränderbar ist. Handelt es sich bei dem Wert um eine Referenz auf ein Objekt, dann kann dieses Objekt trotz der Deklaration mit const
verändert werden. Es gibt allerdings die Möglichkeit, auch Objekte immutable zu machen, so dass die Aussage auf diesen Fall erweitert werden kann. ↩︎
Was soll aber passieren, wenn man das Formular an einem Tag öffnet (sagen wir um 23:55), aber erst am nächsten Tag ausfüllt?
Sa sollte im vorliegenden Fall kein Problemsein, denn es geht offenbar um ein Kaufdatum in der Vergangenheit. Also wahrscheinlich um eine nachfolgende Bewertung, Reklamationsbearbeitung, Auslieferungsfristenkontrolle oder was auch immer. In jedem Fall dürfte es "ziemlich selten" vorkommen, dass jemand die Seite am 1. Foorian vorsorglich öffnet um am 2. Foorian zu kaufen und das Datum sodann also in die am 1. Foorian geöffnete Seite eintragen zu wollen, was sodann am max
scheitert.
Soll heißen, bei einer anderer Anwendung kann es schon zu dem Problem kommen. Stellt sich die Frage, in welchem Fall man wohl das aktuelle Datum überhaupt selbst angibt.
@@Rolf B
kaufDatum.max = new Date().toISOString().substring(0,10);
“The toISOString()
method returns a string in simplified extended ISO format (ISO 8601), which is always 24 or 27 characters long (YYYY-MM-DDTHH:mm:ss.sssZ
or ±YYYYYY-MM-DDTHH:mm:ss.sssZ
, respectively).” [MDN]
Ist es sichergestellt, dass alle Client in die Jahreszahl in den Jahren 0 bis 9999 vierstellig angeben? Wenn nicht, müsste man sowas machen:
const nowISOString = new Date().toISOString();
kaufDatum.max = nowISOString.substring(0, nowISOString.indexOf('T'));
LLAP 🖖