Jnnbo: Datumsformat für Erinnerungsfunktion

Guten Morgen,

ich möchte gerne eine Erinnerungsfunktion in meine Artikeldatenbank einfügen. Das Datum soll händisch (später vielleicht über ein Kalender) über ein Textfeld in „deutsch“ also z.B. 28.04.2015 eingeben werden. Eine Uhrzeit ist nicht wichtig. Mit dem Datum sollte im zweiten Schritt eine Mail an mich verschickt werden und zwar an dem Tag, wo auch die Erinnerung gesetzt ist. Das Script löse ich jeden Tag einmal von Hand aus.

Wie müsste ich das Datum in der Datenbank speichern?

akzeptierte Antworten

  1. Hallo Jnnbo,

    Wie müsste ich das Datum in der Datenbank speichern?

    Es würde sich anbieten das im TIMESTAMP-Format zu speichern. Parsen musst du das von Hand angegebene Datum ja eh, wenn das deine Bedenken auslöst.

    LG,
    CK

    1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

      Wie müsste ich das Datum in der Datenbank speichern?

      Es würde sich anbieten das im TIMESTAMP-Format zu speichern. Parsen musst du das von Hand angegebene Datum ja eh, wenn das deine Bedenken auslöst.

      Welchen Vorteil könnte das haben gegenüber einem Datumsformat des DBMS?

      Spirituelle Grüße
      Euer Robert
      robert.r@online.de

      --
      Möge der wahre Forumsgeist ewig leben!
      1. Hallo robertroth,

        Es würde sich anbieten das im TIMESTAMP-Format zu speichern. Parsen musst du das von Hand angegebene Datum ja eh, wenn das deine Bedenken auslöst.

        Welchen Vorteil könnte das haben gegenüber einem Datumsformat des DBMS?

        Das ist ein „Datumsformat“ (es ist ein Datentyp, kein Format) des DBMS.

        LG,
        CK

        1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

          Hallo robertroth,

          Es würde sich anbieten das im TIMESTAMP-Format zu speichern. Parsen musst du das von Hand angegebene Datum ja eh, wenn das deine Bedenken auslöst.

          Welchen Vorteil könnte das haben gegenüber einem Datumsformat des DBMS?

          Das ist ein „Datumsformat“ (es ist ein Datentyp, kein Format) des DBMS.

          Schade!
          Ich denke, dass Du mich schon verstanden hast.
          Warum beantwortest Du dann nicht auch die eigentliche Frage?

          Eine Vorlesung über die richtigen Begriffe kannst Du doch trotzdem halten :-p

          Spirituelle Grüße
          Euer Robert
          robert.r@online.de

          --
          Möge der wahre Forumsgeist ewig leben!
          1. Hallo robertroth,

            Es würde sich anbieten das im TIMESTAMP-Format zu speichern. Parsen musst du das von Hand angegebene Datum ja eh, wenn das deine Bedenken auslöst.

            Welchen Vorteil könnte das haben gegenüber einem Datumsformat des DBMS?

            Das ist ein „Datumsformat“ (es ist ein Datentyp, kein Format) des DBMS.

            Schade!
            Ich denke, dass Du mich schon verstanden hast.

            Offensichtlich nicht.

            Warum beantwortest Du dann nicht auch die eigentliche Frage?

            Habe ich doch. Was war denn deine eigentliche Frage?

            Eine Vorlesung über die richtigen Begriffe kannst Du doch trotzdem halten :-p

            Du brauchst bei mir grundsätzlich keine Böswilligkeit zu unterstellen, das ist nicht meine Art. Wenn ich eine Frage nicht hinreichend auf deine Bedürfnisse beantworte, dann liegt das daran, dass ich nicht das eigentliche Ziel der Frage erfassen konnte.

            LG,
            CK

            1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

              Es würde sich anbieten das im TIMESTAMP-Format zu speichern. Parsen musst du das von Hand angegebene Datum ja eh, wenn das deine Bedenken auslöst.

              Welchen Vorteil könnte das haben gegenüber einem Datumsformat des DBMS?

              Das ist ein „Datumsformat“ (es ist ein Datentyp, kein Format) des DBMS.

              Schade!
              Ich denke, dass Du mich schon verstanden hast.

              Offensichtlich nicht.

              Warum beantwortest Du dann nicht auch die eigentliche Frage?

              Habe ich doch. Was war denn deine eigentliche Frage?

              Eine Vorlesung über die richtigen Begriffe kannst Du doch trotzdem halten :-p

              Du brauchst bei mir grundsätzlich keine Böswilligkeit zu unterstellen, das ist nicht meine Art. Wenn ich eine Frage nicht hinreichend auf deine Bedürfnisse beantworte, dann liegt das daran, dass ich nicht das eigentliche Ziel der Frage erfassen konnte.

              Ich nehms ja auch nicht übel. Ein paar Frotzeleien gehören hier ja scheinbar zum guten Ton.

              Na dann nochmal:

              Was könnte der Vorteil des Spaltentyps TIMESTAMP gegenüber den Spaltentypen DATETIME oder DATE, oder entsprechenden Spaltentypen des jeweiligen DBMS sein?

              Spirituelle Grüße
              Euer Robert
              robert.r@online.de

              --
              Möge der wahre Forumsgeist ewig leben!
              1. Hallo robertroth,

                Was könnte der Vorteil des Spaltentyps TIMESTAMP gegenüber den Spaltentypen DATETIME oder DATE, oder entsprechenden Spaltentypen des jeweiligen DBMS sein?

                DATE ist ein Datum ohne Zeit-Angabe. Wenn du keine Zeit brauchst, bietet sich dieser Datentyp an.

                DATETIME und TIMESTAMP sind bei PostgreSQL äquivalent. Bei MySQL hat TIMESTAMP einen anderen Wertebereich als DATETIME und es wird intern in UTC gespeichert.

                Welchen genau man braucht, hängt also von den Daten ab. Z.B. braucht man bei MySQL für Zeitpunkte < 1.1.1970 00:00 GMT prinzipiell DATETIME.

                LG,
                CK

                1. Hallo robertroth,

                  Was könnte der Vorteil des Spaltentyps TIMESTAMP gegenüber den Spaltentypen DATETIME oder DATE, oder entsprechenden Spaltentypen des jeweiligen DBMS sein?

                  DATE ist ein Datum ohne Zeit-Angabe. Wenn du keine Zeit brauchst, bietet sich dieser Datentyp an.

                  DATETIME und TIMESTAMP sind bei PostgreSQL äquivalent. Bei MySQL hat TIMESTAMP einen anderen Wertebereich als DATETIME und es wird intern in UTC gespeichert.

                  Welchen genau man braucht, hängt also von den Daten ab. Z.B. braucht man bei MySQL für Zeitpunkte < 1.1.1970 00:00 GMT prinzipiell DATETIME.

                  Und so sehr weit in die Zukunft fliegen kann man mit TIMESTAMP (in Standardsystemen) auch nicht mehr. TIMESTAMP

                  1. Hallo

                    Und so sehr weit in die Zukunft fliegen kann man mit TIMESTAMP (in Standardsystemen) auch nicht mehr. TIMESTAMP

                    Nu komm, das reicht mithin bis zum frühen Morgen des 19.01.2038. Für einen Großteil der Anwendungen auf Webseiten reicht das (vorerst). Wer in größeren Zeiträumen planen muss und wer sich dieses Problems erst Mitte der dreißiger Jahre dieses Jahrhunderts anzunehmen hat, muss halt drüber nachdenken. Zudem ist anzunehmen, dass es bis dahin andere geeignete Datentypen mit entsprechender Verbreitung geben wird.

                    Tschö, Auge

                    --
                    Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war. Terry Pratchett, “Wachen! Wachen!
                    1. Liebe Mitdenker, liebe Wissende, liebe Neugierige,

                      Und so sehr weit in die Zukunft fliegen kann man mit TIMESTAMP (in Standardsystemen) auch nicht mehr. TIMESTAMP

                      Nu komm, das reicht mithin bis zum frühen Morgen des 19.01.2038. Für einen Großteil der Anwendungen auf Webseiten reicht das (vorerst). Wer in größeren Zeiträumen planen muss und wer sich dieses Problems erst Mitte der dreißiger Jahre dieses Jahrhunderts anzunehmen hat, muss halt drüber nachdenken. Zudem ist anzunehmen, dass es bis dahin andere geeignete Datentypen mit entsprechender Verbreitung geben wird.

                      (Erb-)Pachtverträge kannst Du damit schon nicht mehr verwalten. :-)

                      und ich hab da noch einen interessanten Link gefunden. Da hat sich Jemand mal etwas Arbeit gemacht. Zeitdatentypen

                      Spirituelle Grüße
                      Euer Robert
                      robert.r@online.de

                      --
                      Möge der wahre Forumsgeist ewig leben!
                      1. Hallo

                        Nu komm, das reicht mithin bis zum frühen Morgen des 19.01.2038. Für einen Großteil der Anwendungen auf Webseiten reicht das (vorerst). Wer in größeren Zeiträumen planen muss und wer sich dieses Problems erst Mitte der dreißiger Jahre dieses Jahrhunderts anzunehmen hat, muss halt drüber nachdenken. Zudem ist anzunehmen, dass es bis dahin andere geeignete Datentypen mit entsprechender Verbreitung geben wird.

                        (Erb-)Pachtverträge kannst Du damit schon nicht mehr verwalten. :-)

                        Deshalb ja: „Wer in größeren Zeiträumen planen muss …“

                        und ich hab da noch einen interessanten Link gefunden. Da hat sich Jemand mal etwas Arbeit gemacht. Zeitdatentypen

                        Den hatte ich schon.

                        Eine Bitte an die geneigte Leserschaft: Der Blogartikel bezieht sich primär auf den MS SQL Server. Gerade MySQL kocht ja in Sachen Datentypen das eine oder andere Extrasüppchen. Also bleibt immer die Aufgabe, solche Artikel mit der Doku des eigenen SQL-Servers abzugleichen. Das gilt auch für die verschiedenen Versionen des SQL-Servers von MS. Da kommt ja auch pro Versionssprung das Eine oder Andere hinzu.

                        Tschö, Auge

                        --
                        Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war. Terry Pratchett, “Wachen! Wachen!
      2. Tach!

        Es würde sich anbieten das im TIMESTAMP-Format zu speichern. Parsen musst du das von Hand angegebene Datum ja eh, wenn das deine Bedenken auslöst.

        Welchen Vorteil könnte das haben gegenüber einem Datumsformat des DBMS?

        Wenn es um PostgreSQL ginge, dann gibts da nur TIMESTAMP neben DATE, TIME und INTERVAL. Bei MySQL hingegen hat TIMESTAMP eine Sonderbedeutung mit eingebauter Magie. DATETIME wäre MySQLs Äquivalent zu TIMESTAMP. Zeit braucht es aber nicht, also wäre in beiden Fällen DATE ausreichend.

        dedlfix.

        1. Hallo dedlfix,

          Wenn es um PostgreSQL ginge, dann gibts da nur TIMESTAMP neben DATE, TIME und INTERVAL. Bei MySQL hingegen hat TIMESTAMP eine Sonderbedeutung mit eingebauter Magie. DATETIME wäre MySQLs Äquivalent zu TIMESTAMP. Zeit braucht es aber nicht, also wäre in beiden Fällen DATE ausreichend.

          Ok, dann nehme ich 'DATE' dann habe ich auch ein Datum das ich lesen kann, wenn ich nur kurz in die Datenbank schaue.

        2. Hallo dedlfix,

          Bei MySQL hingegen hat TIMESTAMP eine Sonderbedeutung mit eingebauter Magie.

          Die UPDATE-Magie ist inzwischen auch bei DATETIME aktiv (seit MySQL 5.6 iirc).

          LG,
          CK

          1. Tach!

            Bei MySQL hingegen hat TIMESTAMP eine Sonderbedeutung mit eingebauter Magie.

            Die UPDATE-Magie ist inzwischen auch bei DATETIME aktiv (seit MySQL 5.6 iirc).

            Aha! Dann ist da wohl kein Unterschied mehr. Aber es gibt trotzdem noch einen. TIMESTAMP wandelt von der aktuellen Zeitzone nach UTC und wieder zurück, DATETIME macht das nicht.

            dedlfix.

            1. Hallo dedlfix,

              Bei MySQL hingegen hat TIMESTAMP eine Sonderbedeutung mit eingebauter Magie.

              Die UPDATE-Magie ist inzwischen auch bei DATETIME aktiv (seit MySQL 5.6 iirc).

              Aha! Dann ist da wohl kein Unterschied mehr. Aber es gibt trotzdem noch einen. TIMESTAMP wandelt von der aktuellen Zeitzone nach UTC und wieder zurück, DATETIME macht das nicht.

              Der Werte-Bereich ist auch unterschiedlich. Siehe auch ;-)

              LG,
              CK

    2. Hallo Christian,

      Es würde sich anbieten das im TIMESTAMP-Format zu speichern. Parsen musst du das von Hand angegebene Datum ja eh, wenn das deine Bedenken auslöst.

      hat ein 'TIMESTAMP' nicht auch eine Uhrzeit?, die ich in meinem Fall nicht benötige, oder lass ich dann automatisch immer hh:mm:ss = 00:00:00?

      1. Hallo Jnnbo,

        Es würde sich anbieten das im TIMESTAMP-Format zu speichern. Parsen musst du das von Hand angegebene Datum ja eh, wenn das deine Bedenken auslöst.

        hat ein 'TIMESTAMP' nicht auch eine Uhrzeit?, die ich in meinem Fall nicht benötige, oder lass ich dann automatisch immer hh:mm:ss = 00:00:00?

        Ah, dass du die Uhrzeit nicht brauchst war mir nicht klar. In dem Fall reicht, wie dedlfix sagte, DATE.

        LG,
        CK

  2. Tach!

    Wie müsste ich das Datum in der Datenbank speichern?

    Wenn nicht ganz gewichtige Gründe dagegen sprechen, immer als Datum. Der MySQL-Typ DATE bietet sich an.

    dedlfix.

  3. Moin,

    ist es möglich so ein Format "2015-04-22" in "22.04.2015" umzuwandeln? Unter PHP.net habe ich dazu leider nichts gefunden.

    Der Wert steckt hier drin:

    <?php echo htmlspecialchars($array['ke_datum']); ?>
    
    1. Hi,

      ist es möglich so ein Format "2015-04-22" in "22.04.2015" umzuwandeln?

      ja. auf-split-ten an den -, und dann wieder in der gewünschten Reihenfolge mit den gewünschten Trennzeichen zusammensetzen.

      Hat aber nichts mit englischem Format zu tun, das 2015-04-22 ist ISO. Englisch wäre 22/04/2015 (amerikanisch wäre 04/22/2015).

      cu,
      Andreas a/k/a MudGuard

      1. Hallo MudGuard,

        ja. auf-split-ten an den -, und dann wieder in der gewünschten Reihenfolge mit den gewünschten Trennzeichen zusammensetzen.

        wäre es dann nicht einfacher das Datum direkt in diesem "22.04.2015" in der Datenbank zu speichern? Mit hat man empfohlen der Feldtype "Date" zu nutzen.

        Und wie kann ich ein Datum splitten?

        Ich möchte mit dem Datum weiter arbeiten und zwar dass mit MySQL alle Daten liefert, die zum heutigen Tag bzw. alles was in der Vergangenheit liegt liefert.

        EDIT: OK mit http://php.net/manual/de/function.explode.php kann ich wohl das Datum splitten.

        1. Hallo,

          ok, so kann ich also das Datum splitten:

          $teile = explode("-", $array['ke_datum']);
          <?php echo htmlspecialchars($teile[2] .".".$teile[1].".".$teile[0]); ?>
          

          Jetzt bleibt eben die Frage, wie hier schon gefragt, ist es nicht sinnvoller das Datum direkt in dem Deutschen Format zu speichern?

        2. Tach!

          ja. auf-split-ten an den -, und dann wieder in der gewünschten Reihenfolge mit den gewünschten Trennzeichen zusammensetzen.

          Das muss man aber nicht zu Fuß machen. Dieses genormte Format kann von strtotime() interpretiert werden und auch von der Date-Klasse.

          wäre es dann nicht einfacher das Datum direkt in diesem "22.04.2015" in der Datenbank zu speichern? Mit hat man empfohlen der Feldtype "Date" zu nutzen.

          Wenn du es als String speicherst, ist es kein Datum mehr und du kannst keine Datumsberechnungen und -vergleiche mehr damit anstellen. Wenn du es in PHP nicht als Datum brauchst, sondern nur als String nimmst und zur Ausgabe durchreichst, kannst du es ja von der Datenbank gleich formatiert liefern lassen. MySQL hat dazu entsprechende Funktionen.

          dedlfix.

      2. @@MudGuard

        ja. auf-split-ten an den -, und dann wieder in der gewünschten Reihenfolge mit den gewünschten Trennzeichen zusammensetzen.

        Hat aber nichts mit englischem Format zu tun, das 2015-04-22 ist ISO. Englisch wäre 22/04/2015 (amerikanisch wäre 04/22/2015).

        Schreibt das irgendein Ami so? Ich denke, amerikanisch[^1] wäre 4/22/15.

        Was zeigt, dass die Idee, mit Stringverarbeitung ranzugehen, nicht die beste ist.

        Sinnvoller wäre wohl – wie dedlfix schon sagte – das Datum als solches einzulesen und im gewünschten Format auszugeben.

        LLAP

        --
        „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer) [^1]: Wo immer hier „amerikanisch“ steht, ist „US-amerikanisch“ gemeint.
  4. Moin,

    hab heute etwas an meiner Funktion gearbeitet, allerdings wird jetzt überhaupt kein Datensatz mehr ausgegeben:

    	function kundenerinnerungen_User($mysqli, $userCode) {
    
    		$timestamp = time(); 
    		$tagesdatum = date("Y-m-d",$timestamp); 
    
    		$stmt = $mysqli->prepare("SELECT ke_id, ke_userCode, ke_Kdnr, ke_grund, ke_notiz, ke_datum, kd_code, kd_firma, kd_name, kd_vorname, we_id, we_titel 
    					FROM web_kundenerinnerungen
    					LEFT JOIN web_kunden ON web_kunden.kd_code = web_kundenerinnerungen.ke_Kdnr
    					LEFT JOIN web_erinnerungen ON web_erinnerungen.we_id = web_kundenerinnerungen.ke_grund 
    					WHERE ke_userCode =?
    					AND ke_datum <= $tagesdatum
    								");
    		$stmt->bind_param("s", $userCode);
    		$stmt->execute();
    		$stmt->bind_result($ke_id, $ke_userCode, $ke_Kdnr, $ke_grund, $ke_notiz, $ke_datum, $kd_code, $kd_firma, $kd_name, $kd_vorname, $we_id, $we_titel);
    		$stmt->store_result();
    	 	
    		if($stmt->num_rows() >  0) {     
    			while ($stmt->fetch()){
    				$kundenerinnerungen_User[] = array( 
    					'ke_id' 		=> $ke_id, 
    					'ke_userCode'	=> $ke_userCode,
    					'ke_Kdnr' 		=> $ke_Kdnr, 
    					'ke_grund'		=> $ke_grund,
    					'ke_notiz' 		=> $ke_notiz,
    					'ke_datum'		=> $ke_datum,
    					'kd_code'		=> $kd_code,
    					'kd_firma'		=> $kd_firma,
    					'kd_name'		=> $kd_name,
    					'kd_vorname'	=> $kd_vorname,
    					'we_id'			=> $we_id,
    					'we_titel'		=> $we_titel
    				);
    			}
    			return $kundenerinnerungen_User;
    			}
    	}
    

    es liegt an dieser Zeile Code "AND ke_datum <= $tagesdatum" damit möchte ich erreichen, dass alle Datensätze ausgegeben werden, die das heutige Datum haben und oder ein älteres Datum also z.B. den 21.04.2015

    Hab auch schon versucht "<" zu drehen, keine Auswirkungen.

    1. Moin,

      ok, es geht so:

      [....]
      AND ke_datum <= ?");
      $stmt->bind_param("ss", $userCode, $tagesdatum);
      [....]
      
    2. Tach!

        $timestamp = time(); 
        $tagesdatum = date("Y-m-d",$timestamp); 
      

      Wenn man date() ohne zweiten Parameter aufruft, wird die aktuelle Zeit genommen.

        			AND ke_datum <= $tagesdatum
      

      Im Statement steht nun AND ke_datum <= 2015-04-23. Das sieht aus wie ein Datum, ist aber für MySQL eine zweifache Subtraktion. Wenn man Prepared Statements verwendet, dann kann man das auch ruhig konsequent machen, und vergisst keine Anführungszeichen.

      dedlfix.