Datumsformat für Erinnerungsfunktion
Jnnbo
- datenbank
- php
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?
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
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
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
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
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
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
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
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
undTIMESTAMP
sind bei PostgreSQL äquivalent. Bei MySQL hatTIMESTAMP
einen anderen Wertebereich alsDATETIME
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
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
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
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
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.
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.
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
Tach!
Bei MySQL hingegen hat TIMESTAMP eine Sonderbedeutung mit eingebauter Magie.
Die
UPDATE
-Magie ist inzwischen auch beiDATETIME
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.
Hallo dedlfix,
Bei MySQL hingegen hat TIMESTAMP eine Sonderbedeutung mit eingebauter Magie.
Die
UPDATE
-Magie ist inzwischen auch beiDATETIME
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
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?
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
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.
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']); ?>
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
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.
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.
@@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
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.
Moin,
ok, es geht so:
[....]
AND ke_datum <= ?");
$stmt->bind_param("ss", $userCode, $tagesdatum);
[....]
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.