input type=date verlass auf formatierung? Und Datumbereich filtern

[Henry]

Hallo,

ein Inputfeld als Datum aktiviert ja mittlerweile netterweise einen internen Kalender. Die Ausgabe hat das Foramt zb. 2021-04-24. Ist darauf Verlass?

Ich meine damit, ist das unabhängig von Browser, OS, lokale Einstellungen, usw. langfristig gesichert?

Dann noch eine 2te Frage. Wenn ich mit PHP eine Datei/Array nach Datumbereich filtern möchte, habe ich immer mal wieder verschiedene Ansätze. Die funktionieren zwar aber sind eben uneinheitlich daher wüsste ich doch mal gerne wie ihr das lösen würdet.

Gegeben:

  [92] => Array
        (
            [0] => 01.01.2021
            [1] => 27327.76

        )

    [93] => Array
        (
            [0] => 03.01.2021
            [1] => 15427.76

        )

    [94] => Array
        (
            [0] => 01.02.2021
            [1] => 45827.76

        )

    [95] => Array
        (
            [0] => 02.03.2021
            [1] => 57427.76
        )…   

Wie würdet ihr jetzt so eine Liste mit PHP nach Datum filtern, also zb. nur Februar oder zb. nur von 12.02.2021-03.05.2021? Vor allem auf Grundlage input type=date

Gruss
Henry

[dedlfix]

Tach!

ein Inputfeld als Datum aktiviert ja mittlerweile netterweise einen internen Kalender. Die Ausgabe hat das Foramt zb. 2021-04-24. Ist darauf Verlass?

Die Frage lässt sich beantworten, indem man einen Blick in die Spezifikation wirft.

Ich meine damit, ist das unabhängig von Browser, OS, lokale Einstellungen, usw. langfristig gesichert?

Nein. Wenn der Browser alt ist und das Feld wie text behandelt, bekommst du nicht unbedingt einen erwarteten Wert. Ansonsten wird dir letztlich keiner eine Garantie für Fehlerfreiheit und Zukunftssicherheit gegeben. Man könnte aber davon ausgehen, dass das System hinreichend stabil ist, wenn die Browser type=date unterstützen.

Wie würdet ihr jetzt so eine Liste mit PHP nach Datum filtern, also zb. nur Februar oder zb. nur von 12.02.2021-03.05.2021? Vor allem auf Grundlage input type=date

Wenn die Darstellung des Datums ein sortierfähiger String ist, lässt sich das Problem mit Stringfunktionen lösen. Ansonsten kann man das Datum zuerst umformatieren. Oder man parst es zu einem vom System bereitgestellten Typ, und nimmt ebenfalls bereitgestellte Funktionalität für weitere Berechnungen. Zur Not gibt man es als formatierten sortierfähigen String aus und verfährt weiter wie im ersten Punkt.

dedlfix.

[Rolf B]

Hallo Henry,

(Edit: Als ich anfing zu schreiben, war dedlfix' Antwort noch nicht da...)

ein Inputfeld als Datum aktiviert ja mittlerweile netterweise einen internen Kalender. Die Ausgabe hat das Foramt zb. 2021-04-24. Ist darauf Verlass?

Nein. Weil kein Verlass darauf ist, dass input type="date" unterstützt wird. Vom IE will ich ja gar nicht reden, aber MDN gibt auch für den Safari an, dass die Unterstützung rot sei.

Wenn type=date unterstützt wird, dann ist das Format der value-Eigenschaft als "proleptisches Gregorianisches Datum im Format yyyy-mm-dd" spezifiziert.

(1) https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date) (2) https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#dates

Du kommst also um eine serverseitige Validierung nicht herum. Ob Du IE+Safari User zwingen willst, das Datum als yyyy-mm-dd einzugeben, ist Deine Entscheidung. Eventuell solltest Du auch [d]d.[m]m.[yy]yy und [m]m/[d]d/[yy]yy akzeptieren (Punkt für dmy und / für mdy - ich weiß, dass das suboptimal ist, aber bei Datümern ist der kulturelle Einfluss so gewaltig, dass man allein aus Datumseingaben schon ein Projekt machen kann).

Mit JavaScript auf dem Client kannst Du sicherlich ermitteln, ob type=date unterstützt wird (zum "Wie" müsste ich jetzt selbst recherchieren) und im Ja-Fall einen Info-Text zum Datumsformat verstecken (nicht im Nein-Fall einblenden, weil JS ggf. auch nicht läuft).

Wie würdet ihr jetzt so eine Liste mit PHP nach Datum filtern Vor allem auf Grundlage input type=date

Angesichts dessen, was ich sehe, würde ich das bleiben lassen, weil diese Liste das Datum in einem Format enthält, das für eine Computerverarbeitung ungeeignet ist: String im TT.MM.YYYY Format. Die Aufbereitung eines Datums in die vom Benutzer gewünschte Form übernimmt man nicht nach der Eingabe, sondern vor der Ausgabe. Nach der Eingabe übersetzt man Datumswerte in maschinenkompatible Formate, d.h. zumindest in einen YYYY-MM-DD String oder - viel besser - in ein DateTime oder DateTimeImmutable Objekt.

Dann ist die Verknüpfung von "wie filtere ich das" mit "type=date" irrelevant. Und die Frage "wie filtere ich das" ist trivial. Wenn Du alles aus dem Februar 2021 wissen willst, dann machst Du es so:

$min = new DateTimeImmutable("2021-02-01");
$max = $min->add(new DateInterval("P1M"));

foreach ($tabelle as $eintrag)
{
   if ($eintrag[0] >= $min && $eintrag[0] < $max)
   {
      // found some!
   }
}

Wenn Du für $min ein normales DateTime nimmst, wird es vom add modifiziert. Das willst Du nicht, darum DateTimeImmutable.

DateInterval::__construct bekommt einen Periodenstring als Eingabe, der beginnt immer mit P - guckst Du hier.

Statt foreach geht's natürlich auch kompakter (Arrow-Functions ab PHP 7.4):

$checkDateRange = fn($eintrag) => $eintrag[0] >= $min && $eintrag[0] < $max;
print_r(array_filter($tabelle, $checkDateRange);

Rolf

[Gunnar Bittersmann]

@@Rolf B

Nein. Weil kein Verlass darauf ist, dass input type="text" unterstützt wird.

Nicht? 😉

Ich hab das mal in deinem Beitrag editiert.

aber MDN gibt auch für den Safari an, dass die Unterstützung rot sei.

Huch? Konnte Safari das nicht schon mal?

Bin mir fast sicher, auf dem iPhone die hauseigenen Walzen als Datepicker gesehen zu haben. Fata morgana?

😷 LLAP

[Rolf B]

Hallo Gunnar,

Ich hab das mal in deinem Beitrag editiert.

Ups 😲 - danke 😀

Es geht nicht um iOS-Safari, nur um die Desktop-Version. Die scheinen unterschiedlich zu sein. MDN sagt zur Kompatibilität beim "großen" Safari:

The input type is recognized, but there is no date-specific control.

Dieser Vermerk mag nicht aktuell sein, denn sie verlinken da auch einen offenbar vergessenen Bug von 2013 (sic!), wonach das Control in S5 vorhanden war und mit S6 verschwand - und der letzte Stand ist dieser:

Starting with Safari TP 115, released on Oct 22, 2020, UIs for date, datetime-local and time are supported on macOS and iOS

Was auch immer TP 115 ist.

Rolf

[Auge]

Hallo

Starting with Safari TP 115, released on Oct 22, 2020, UIs for date, datetime-local and time are supported on macOS and iOS

Was auch immer TP 115 ist.

Ich würde das mal als „Technology Preview“ interpretieren wollen. Can I Use bestätigt im Übrigen die von dir zitierte Aussage im Safari-Ticket (Support im TP).

Allgemein scheint es für einige Browserhersteller problematisch zu sein, das Feature vollständig zu implementieren. Die Subfeatures week und month fehlen sowohl im Firefox als auch im Safari (TP, Firefox), zusäntzlich datetime-local im Firefox sowie week, min, max und step im Safari für iOS.

Tschö, Auge