EinJungerMann: Aktuelles Datum als max in ein datums Eingabefeld

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 );
}

akzeptierte Antworten

  1. 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');?>">
    
    1. <?=date('y-m-d');?>
      
      <?=date('Y-m-d');?>
      
    2. 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

      1. Hallo Email,

        Und für die die lieber klicken als 3 Zahlen einzugeben gibs Datumsauswahldialoge.

        Genau. <input type=date>

        Bis demnächst
        Matthias

        --
        Pantoffeltierchen haben keine Hobbys.
        ¯\_(ツ)_/¯
  2. 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?

    • 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. Der Eventhandler ist eine anonyme Funktion, die an addEventListener übergeben wird.
    • In dieser Funktion wird das Element mit der ID kaufDatum gesucht. Wenn es existiert, wird sein max-Attribut gesetzt
    • An Stelle einer handgemachten Aufbereitung wird toISOString() verwendet. Die ersten 10 Stellen davon sind das Datum im Format YYYY-MM-DD. Danach folgt ein T und die Uhrzeit, das brauchen wir nicht, darum wird das Ergebnis von toISOString mittels substr auf die ersten 10 Stellen beschnitten.

    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

    --
    sumpsi - posui - clusi
    1. @@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 🖖

      --
      „Man kann sich halt nicht sicher sein“, sagt der Mann auf der Straße, „dass in einer Gruppe Flüchtlinge nicht auch Arschlöcher sind.“
      „Stimmt wohl“, sagt das Känguru, „aber immerhin kann man sich sicher sein, dass in einer Gruppe Rassisten nur Arschlöcher sind.“

      —Marc-Uwe Kling
      1. 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

        --
        sumpsi - posui - clusi
        1. @@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 🖖

          --
          „Man kann sich halt nicht sicher sein“, sagt der Mann auf der Straße, „dass in einer Gruppe Flüchtlinge nicht auch Arschlöcher sind.“
          „Stimmt wohl“, sagt das Känguru, „aber immerhin kann man sich sicher sein, dass in einer Gruppe Rassisten nur Arschlöcher sind.“

          —Marc-Uwe Kling
          1. 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 = 4function 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 letdeklariert wurden, da eine andere Funktion den Wert jederzeit verändern könnte.

            const y = 2function 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


            1. 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. ↩︎

      2. 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.

    2. @@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 🖖

      --
      „Man kann sich halt nicht sicher sein“, sagt der Mann auf der Straße, „dass in einer Gruppe Flüchtlinge nicht auch Arschlöcher sind.“
      „Stimmt wohl“, sagt das Känguru, „aber immerhin kann man sich sicher sein, dass in einer Gruppe Rassisten nur Arschlöcher sind.“

      —Marc-Uwe Kling
      1. Hallo Gunnar,

        ich bin beeindruckt, bei der ISO berücksichtigt man schon das Jahr-100000 Problem. Ob es JavaScript-Module geben wird, die im dann aktuellen ITCAScript[1] Standard zu berücksichtigen sind?

        Rolf

        --
        sumpsi - posui - clusi

        1. Intergalactic Think Cloud Association - ↩︎