Ankündigung

Einklappen
Keine Ankündigung bisher.

Zeitfehler

Einklappen

Neue Werbung 2019

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

  • #16
    Na Ja, wer von den 2200+ Stars benutzt denn noch 32-bit-systeme?
    Vermute unter 64-bit gibt es das Problem nicht.
    Dann ist es noch so, das ich einen solchen Methodenwald (addMonths(),addMonth(), subMonth(), subMonths(),addDays() usw.usw) nicht mag, da sich das bereits alles mit Datetime::modify erschlagen lässt.
    Wer Krümel in einer Suppe sucht, findet auch welche..

    Kommentar


    • #17
      Ich habe keine Ahnung, wie weit 32-bit-Versionen von PHP noch verbreitet sind. Ich wünsche mir immer, dass Leute auf so was achten, weil ich es immer extrem unbefriedigend finde, wenn Code für manche Eingaben einfach tiltet und irgendeinen Wert zurückliefert, der nicht mal als fehlerhaft zu erkennen ist. Dass 32-bit-Timestamps „bis 2038 reichen“ ist ja jetzt kein großes Geheimnis. Exception oder bool(false) als Rückgabe wäre ja okay. Oder wenigstens ein Hinweis in der Doku, dass es an der Stelle bei 32-bit Dinge zu beachten gibt.

      Ich habe häufig das Gefühl, dass bestimmte Sachen sauber lösbar wären, dass man meist aber lieber eine neue Variante erstellt, die es dann auf andere Weise „falsch“ macht. Das ist ein Auf-der-Stelle-Treten.

      Zitat von fireweasel
      PHP-Code:
      class DateTimeFinalProposalForAnEasterSunday... 
      :thumbsup:

      Kommentar


      • #18
        Bin beim Überfliegen des Codes noch auf ein Problem gestoßen. Ich häng das hier einfach mal an.
        PHP-Code:
        $date1 = new carbon('2014-3-30 00:00:00');
        $date2 = new carbon('2014-3-30 06:00:00');

        //DateTime-Methode
        $diff_h $date1->diff($date2)->h;
        var_dump($diff_h);  //int(6)

        //Carbon-Methode
        $diffInHours $date1->diffInHours($date2);
        var_dump($diffInHours); //int(5) 
        Die Methoden liefern im Normalfall identische Ergebnisse, nicht jedoch wenn zwischen date1 und date2 wie hier dummerweise die Umstellung auf Sommerzeit liegt.
        Die DateTime-Methode liefert die Differenz wie wir die Uhr ablesen, $diffInHours die echt vergangene Zeit, da fehlt ja uns bekannterweise eine Stunde.
        Gibt es hier ein richtig und falsch? Nein, glaube ich zumindest. Aber ein Hinweis was wirklich geliefert wird ist angebracht.

        Insgesamt bietet die Klasse schon eine Menge Features, reinschauen lohnt allemal.

        LG jspit

        Kommentar


        • #19
          Was ist die Fuktion carbon ?

          Kommentar


          • #20
            OT: Sorry, aber bist du ein echter Nutzer oder sammelst du aus irgendwelchen Spam-/SEO-Gründen Beiträge?

            Kommentar


            • #21
              Zitat von j.durini Beitrag anzeigen
              Was ist die Fuktion carbon ?
              Hier: https://github.com/briannesbitt/Carbon


              Fragst du immer erst bevor du einmal zB google verwendest, wie eben im anderen Thread ( http://www.php.de/php-einsteiger/112...tml#post830836 ) ?

              LG
              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


              • #22
                Das ist richtig. Kannte ich gar nicht und hatte ich nie zuvor gehört. Danke trotzdem.

                Kommentar


                • #23
                  Zitat von jspit Beitrag anzeigen
                  Na Ja, wer von den 2200+ Stars benutzt denn noch 32-bit-systeme?
                  Vermute unter 64-bit gibt es das Problem nicht.
                  Zitat von mermshaus Beitrag anzeigen
                  Ich habe keine Ahnung, wie weit 32-bit-Versionen von PHP noch verbreitet sind.
                  Die "offiziellen" Windows-Binaries von php.net besitzen auch in der 64-Bit-Version nur 32-Bit-Integer-Typen.

                  Ich wünsche mir immer, dass Leute auf so was achten, weil ich es immer extrem unbefriedigend finde, wenn Code für manche Eingaben einfach tiltet und irgendeinen Wert zurückliefert, der nicht mal als fehlerhaft zu erkennen ist. Dass 32-bit-Timestamps „bis 2038 reichen“ ist ja jetzt kein großes Geheimnis. Exception oder bool(false) als Rückgabe wäre ja okay. Oder wenigstens ein Hinweis in der Doku, dass es an der Stelle bei 32-bit Dinge zu beachten gibt.
                  Dazu müsste man die Rückgabewerte der verwendeten "internen" PHP-Funktionen auf entsprechende Fehler-Werte (oder geworfene Exceptions) prüfen können. Ich glaube, das geht nicht bei allen. Manche liefern halt einfach int(0) oder etwas ähnlich nutzloses zurück. Wie bspw. die Calendar-Funktionen, die haben aber glücklicherweise ein etwas größeres Gültigkeitsfenster (>9400 Jahre) als der Unix-Timestamp.

                  Zitat von jspit Beitrag anzeigen
                  Die Methoden liefern im Normalfall identische Ergebnisse, nicht jedoch wenn zwischen date1 und date2 wie hier dummerweise die Umstellung auf Sommerzeit liegt.
                  Die DateTime-Methode liefert die Differenz wie wir die Uhr ablesen, $diffInHours die echt vergangene Zeit, da fehlt ja uns bekannterweise eine Stunde.
                  Gibt es hier ein richtig und falsch? Nein, glaube ich zumindest.
                  Ich würde ja zur letzteren Variante (also der von Carbon) tendieren: Wenn ich die Differenz zwischen zwei Zeitpunkten berechne, will ich die verstrichene Zeit wissen, aber nicht die Anzeige-Differenz zwischen zwei Uhren, von denen immer mindestens eine gerade falsch geht.

                  Aber ein Hinweis was wirklich geliefert wird ist angebracht.
                  Sowas erschlägt man am besten mit noch mehr Methoden:
                  Code:
                  ->getWallclockDiff...();
                  ->getUTCDiff...();
                  Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                  Kommentar


                  • #24
                    Zitat von mermshaus Beitrag anzeigen
                    Oder wenigstens ein Hinweis in der Doku, dass es an der Stelle bei 32-bit Dinge zu beachten gibt.
                    Der Hinweis existiert indirekt (soeben gefunden):
                    PHP-Code:
                    //example 32-Bit Win
                    //Create a Carbon instance for the greatest supported date.
                    echo Carbon::maxValue();                               // '2038-01-19 04:14:07 '

                    //Create a Carbon instance for the lowest supported date.
                    echo Carbon::minValue();                               // '1901-12-13 21:45:52 ' 
                    Für solche Systeme ist aber damit aber ein großer Vorteil von DateTime dahin

                    Kommentar


                    • #25
                      Noch 83 Tage bis Ostern ...

                      Zitat von jspit Beitrag anzeigen
                      Der Hinweis existiert indirekt (soeben gefunden):
                      PHP-Code:
                      //example 32-Bit Win
                      //Create a Carbon instance for the greatest supported date.
                      echo Carbon::maxValue();                               // '2038-01-19 04:14:07 '

                      //Create a Carbon instance for the lowest supported date.
                      echo Carbon::minValue();                               // '1901-12-13 21:45:52 ' 
                      Für solche Systeme ist aber damit aber ein großer Vorteil von DateTime dahin
                      DateTime-Objekte können mit Timestamps außerhalb des Bereiches ~PHP_INT_MAX ... PHP_INT_MAX erzeugt werden, selbst wenn das verwendete PHP "32-bittig" ist. Auch ->modify() kann damit umgehen, wenn man die Zahl richtig formatiert (also ohne Dezimalpunkte oder e-Notation). Nur ->setTimeStamp() ist da etwas beschränkt. Der folgende Hack läuft mit einem 32-Bit-PHP-Build unter Windows:

                      PHP-Code:
                      // precautions because PHP sucks regardless of the bytesize of its integer type
                      if (PHP_INT_MAX 0x7fffffff) {
                          
                      // there seem to be enough bits for use
                          
                      class UxTimeInt {
                              const 
                      MIN = ~PHP_INT_MAX;
                              const 
                      MAX PHP_INT_MAX;
                          }
                      }
                      else {
                          
                      // we're running low on bits, so we abuse double() as "int53()"
                          
                      class UxTimeInt {
                              const 
                      MIN = -377705116800.0// -2.pow(53) would be: -9007199254740992.0;
                              
                      const MAX = +253402300799.0// +2.pow(53) would be: +9007199254740992.0;
                          
                      }
                      }

                      class 
                      Silicon extends Carbon {

                          public static function 
                      createFromTimestamp($timestamp$tz null) {
                              
                      // we use number_format() because
                              // neither sprintf('%whatever', $timestamp)
                              // nor "@$timestamp"
                              // do work
                              
                      return static::now($tz)->modify('@' number_format($timestamp0''''));
                          }

                          public static function 
                      maxValue() {
                              return static::
                      createFromTimestamp(UxTimeInt::MAX);
                          }

                          public static function 
                      minValue() {
                              return static::
                      createFromTimestamp(UxTimeInt::MIN);
                          }

                          function 
                      getTimestamp() {
                              return 
                      PHP_INT_MAX 0x7fffffff
                                  
                      parent::getTimestamp()
                                  : (double) 
                      $this->format('U');
                          }

                          function 
                      setTimestamp($timestamp) {
                              return 
                      is_int($timestamp)
                                  ? 
                      parent::setTimestamp($timestamp)
                                  : 
                      $this->modify('@' number_format($timestamp0''''));
                          }


                          
                      // todo: check all the other methods for built-in artifical limits

                      }

                      var_dump(Silicon::minValue());
                      var_dump(Silicon::maxValue());

                      // "-9999-01-01 00:00:00"
                      // "9999-12-31 23:59:59" 
                      Ich denke, ein Zeitraum von knapp 20_000 Jahren ist erstmal genug. Darüber hinaus macht DateTime:: sowieso Ärger, wenn ich mich recht erinnere ...
                      Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                      Kommentar


                      • #26
                        Darüber hinaus macht DateTime:: sowieso Ärger, wenn ich mich recht erinnere ...
                        Kommt drauf an; wenn du "format()" verwendest, umgehst du den 2038-Bug; da dürftest du in Zukunft imho auch keine Probleme haben. Ausserdem denke ich, dass sich in den nächsten PHP-Versionen bzgl. des vielgehassten integer-return-values etwas tun wird.

                        Kommentar


                        • #27
                          Zitat von Phpyton Beitrag anzeigen
                          Kommt drauf an; wenn du "format()" verwendest, umgehst du den 2038-Bug; da dürftest du in Zukunft imho auch keine Probleme haben.
                          Ich dachte da eher an die internen Berechnungen, die dann zu teilweise wunderlichen Ergebnissen führten (weit über das Timestamp-Limit hinaus). Hab jetzt aber keine Beispiele parat. Die braucht man ja so selten.

                          Ausserdem denke ich, dass sich in den nächsten PHP-Versionen bzgl. des vielgehassten integer-return-values etwas tun wird.
                          Du meinst, es besteht tatsächlich noch Hoffnung, dass man dann schon im Jahre 2015[0] mit PHP-Bordmitteln bspw. Dateigrößen verlässlich unter Windows-Betriebssystemen abfragen kann? Oder bezieht sich das nur auf Datums-Arithmetik?

                          --
                          [0] Dateien größer 2 GB gibts mit NTFS seit 1993 und mit FAT32 seit 1996.
                          Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                          Kommentar


                          • #28
                            Float Timestamps auf der Basis von DateTime für eigene Klassenerweiterungen ermöglichen nicht nur einen erweiterten Jahreszahlenbereich, sondern auch ohne großen Aufwand gleich Milli/Mikrosekunden mit zu händeln.


                            PHP-Code:
                            $microSecondsTimeStamp microtime(true);  //float
                            echo dt::create($microSecondsTimeStamp)
                              ->
                            modify('+50 years')
                              ->
                            format('Y-m-d H:i:s.u');
                            //2065-01-13 10:20:27.593751 
                            Für die Umsetzung wird folgende Methode in der Klassenerweiterung benutzt:
                            PHP-Code:
                              //Setzt Float-Timestamp mit UTC-Zeitzone
                              
                            private function setTimestampUTC($unixtimestamp){
                                
                            $seconds floor($unixtimestamp);
                                
                            $secondsFraktion $unixtimestamp $seconds;
                                
                            $basis '1970-01-01 00:00:0'.sprintf('%0.6f',$secondsFraktion);
                                
                                
                            parent::__construct($basis, new DateTimeZone('UTC'));
                                
                            parent::modify(sprintf('%+.0f',(float)$seconds).' Seconds');
                                
                                return 
                            $this;
                              } 
                            Die notwendige Anpassung an die Zeitzone wird in den public-Methoden erledigt.

                            Kommentar

                            Lädt...
                            X