Ankündigung

Einklappen
Keine Ankündigung bisher.

Fixieren von PHP Bugs als Feature

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Fixieren von PHP Bugs als Feature

    Es ärgert mich schon länger das einige Bugs in PHP über zig Jahre bekannt sind und nicht behoben werden. Der Bug wird kurzerhand als Feature deklariert und gut ist.

    Damit ihr versteht wovon ich Rede ein Beispiel.

    Die Funktion date_parse soll ein Datums/Zeit Ausdruck analysieren. Die Funktion liefert ein Array zurück mit den Elementen für Jahr, Monat, Tag etc. Funktioniert bis auf den Tag welcher false liefern sollte wenn kein Tag vorhanden ist wie bei "Feb 2010".
    PHP-Code:
    var_dump(date_parse("Feb 2010")); 
    Für diesen Fall wird aber ["day"]=> int(1) geliefert. Dazu existiert seit 9 Jahren auch ein Kommentar im Manual.

    Ich frage mich warum ist das so? Habe dazu schon einige Bemerkungen im Netz gefunden jedoch daraus nicht schlau geworden.

    LG jspit




  • #2
    Zitat von jspit Beitrag anzeigen
    Funktioniert bis auf den Tag welcher false liefern sollte wenn kein Tag vorhanden ist wie bei "Feb 2010".
    Davon steht in der Doku aber nichts?

    Kommentar


    • #3
      Vielleicht weil als Input Parameter analog zu DateTime erlaubt ist.

      Parameters

      datetime Date/time in format accepted by DateTimeImmutable::__construct().
      Und das auch so tickt, also diese Funtktion das dann quasi als Basis einfach nur noch in ein Array "aufteilt".
      PHP-Code:
      $dt = new DateTime("Feb 2010");
      print_r($dt); 
      DateTime Object
      Code:
      (
          [date] => 2010-02-01 00:00:00.000000
          [timezone_type] => 3
          [timezone] => US/Pacific
      )
      The string "()()" is not palindrom but the String "())(" is.

      Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
      PHP.de Wissenssammlung | Kein Support per PN

      Kommentar


      • #4
        Stimmt, in der Doku steht so gut wie nichts. Oder was soll ich mit:
        Returns associative array with detailed info about given date/time
        anfangen? Das ich ein Array erhalte mit Informationen? Da fehlen irgendwie weitere Angaben.
        Für andere Elemente wird z.T. false geliefert.
        PHP-Code:
        $str '11. Feb, 12:03:45';
        $array date_parse($str);

        /*
        array (
          'year' => false,
          'month' => 2,
          'day' => 11,
          'hour' => 12,
          'minute' => 3,
          'second' => 45,
          'fraction' => 0.0,
          'warning_count' => 0,
          'warnings' => 
          array (
          ),
          'error_count' => 0,
          'errors' => 
          array (
          ),
          'is_localtime' => false,
        )
        */ 
        Hier wird 'year' als false ausgewiesen. Womöglich sehe ich da die Logik nur nicht wann false gesetzt wird und wann sozusagen ein Defaultwert geliefert wird.

        Kommentar


        • #5
          Zitat von jspit Beitrag anzeigen
          Es ärgert mich schon länger das einige Bugs in PHP über zig Jahre bekannt sind und nicht behoben werden. Der Bug wird kurzerhand als Feature deklariert und gut ist.
          [...]
          Für diesen Fall wird aber ["day"]=> int(1) geliefert. Dazu existiert seit 9 Jahren auch ein Kommentar im Manual.
          Für Bugs gibts bugs.php.net, die Kommentare sind der falsche Platz dafür. Es gibt auch ein Ticket https://bugs.php.net/bug.php?id=69661 das ist aber noch offen. Da hat sich noch niemand gefunden der Lust drauf hat das zu fixen.
          Das Problem ist, dass date_parse() die interne Datenstruktur von strtotime() (und co) exposed. Für strtotime() ist definiert das ein Monat ohne Tag der 1te ist. Unglücklicherweise ist die Regel an einer "ungünstigen" Stelle implementiert wurden. Das zu fixen würde einige Anpassungen nach sich zeihen.

          Kommentar


          • #6
            Zitat von jspit Beitrag anzeigen
            Ich frage mich warum ist das so? Habe dazu schon einige Bemerkungen im Netz gefunden jedoch daraus nicht schlau geworden.
            Entweder interessiert es keinen, da das Verhalten nicht ein ausreichend grosses Problem ist oder es gibt keine gute Lösung die keine anderen Probleme verursachen würde.

            Kommentar


            • #7
              Ich halte das Verhalten für richtig/plausibel. Wenn man "Feb 2010" als Datum haben will, dann würde ich 2010-02-01 (00:00:00) als Datum erwarten. Möglich wäre ggf tatsächlich den Tag auf NULL zu setzen und diesen dann ggf über Null-Coalesce-Operator zu etwas zu machen, was man an der Stelle am ehesten braucht.

              False hingegen wäre komplett fail.

              Kommentar


              • #8
                hm, für mich ist es schwierig zu beantworten was hier richtig wäre. Andere Funktionen wie parse_url arbeiten in dem Fall auch nicht richtig wenn die URL nur zum Teil angegeben wird. Vielleicht sollte man in so einem Fall einfach seine eigene Funktion schreiben, Ansätze dazu gibt es ja bereits in den Kommentaren.

                Kommentar


                • #9
                  Zitat von rkr Beitrag anzeigen
                  Ich halte das Verhalten für richtig/plausibel. Wenn man "Feb 2010" als Datum haben will, dann würde ich 2010-02-01 (00:00:00) als Datum erwarten.
                  Was strtotime und new DateTime aus solchen Ausdrücken machen ist eine andere Baustelle. Dort ist das Ok. date_parse() liefert Informationen zu einzelnen Bestandteilen. Diese werden jedoch nicht einheitlich behandelt.
                  Hier setzt meine Kritik an.
                  Fehlt das Jahr, liefert date_parse() wie unter #4 zu sehen für das Jahr false (und DateTime nimmt das aktuelle Jahr). Fehlt dagegen der Tag, liefert date_parse() nicht false sondern eine 1.

                  Es ist vermutlich so wie von erc und Blar beschrieben.

                  protestix Hab schon versucht das nur für den Tag zu richten. Gar nicht so einfach bei der Vielfalt der möglichen Datumsausdrücke.
                  ​​​​​​​

                  Kommentar

                  Lädt...
                  X