Datetime vergleichen

[Twilo]

Hallo,

ich möchte eigentlich nur ein Datetimefeld vergleichen

ich hab filgenden Ansatz

$db->setWhere('_reg_date>now()-300');
bei dieser Variante bekomme ich keine Datensätze angezeigt

wenn ich aber
$db->setWhere('_reg_date>now()-3600');
verwende, bekomme ich auf einmal alle Datensätze ausgegeben

gehe ich richtig der Annahme, dass -300 bzw. -3600 Sekunden abzieht?
so entnehme ich das auf jedenfall von hier http://dev.mysql.com/doc/mysql/de/Date_and_time_functions.html

ich möchte, dass mir Datensätze angezeigt werden, die jünger als z.B. 3600 Sekunden sind

irgendwie versteh ich das ganze nicht
wäre nett, wenn ihr mir etwas auf die Sprünge hilft

mfg
Twilo

[Twilo]

Hallo,

ich hab es jetzt so hinbekommen
$db->setWhere('_reg_date>FROM_UNIXTIME(unix_timestamp()-3600)');

geht das nicht noch etwas kürzer?

mfg
Twilo

[Rolf Rost]

Hallo,

ich möchte, dass mir Datensätze angezeigt werden, die jünger als z.B. 3600 Sekunden sind

irgendwie versteh ich das ganze nicht
wäre nett, wenn ihr mir etwas auf die Sprünge hilft

Gerne ;-)

Also in meinen Datenbanken sind Datums- o.a. Zeitangaben grundsätzlich als integer Zahlen abgelegt => als seconds since begin of the epoch 1.1.1970. Das macht viele Dinge einfacher, z.B. die Darstellung als gmtime oder localtime in den Formaten wie sie gerade gebraucht werden (mit Sekunden, ohne Sekungen, 1.1.2004, 010104 usw.) oder das Rechnen mit solchen Daten oder das Sortieren...

Gruss, Rolf

[wahsaga]

hi,

Also in meinen Datenbanken sind Datums- o.a. Zeitangaben grundsätzlich als integer Zahlen abgelegt => als seconds since begin of the epoch 1.1.1970. Das macht viele Dinge einfacher, z.B. die Darstellung als gmtime oder localtime in den Formaten wie sie gerade gebraucht werden (mit Sekunden, ohne Sekungen, 1.1.2004, 010104 usw.) oder das Rechnen mit solchen Daten oder das Sortieren...

da muss ich widersprechen - in mysql bietet es sich eigentlich eher an, die dort vorhandenen datums- und zeit-typen zu benutzen, weil die für eine vielzahl von berechnungen und vergleichen mit den vorhandenen mitteln von mysql einfacher zu handhaben sind, als ein unit-timestamp.

gruß,
wahsaga

[Rolf Rost]

hi,

vielen Dank!

da muss ich widersprechen - in mysql bietet es sich eigentlich eher an, die dort vorhandenen datums- und zeit-typen zu benutzen, weil die für eine vielzahl von berechnungen und vergleichen mit den vorhandenen mitteln von mysql einfacher zu handhaben sind, als ein unit-timestamp.

Also in meinen Script überwiegen eigene Funktionen in der Zahl derer die MySQL selbst bereitstellt um irgendwelche Datumsberechnungen zu machen ;-)

Btw., das Sortieren nach integer Spalten geht genauso wie das Sortieren nach Spalten vom type date.

Der entscheidene Vorteil ergibt sich ME in der Scalierbarkeit der Darstellung eines Date-Formates ("%m.%d.%Y %H:%M" als Beispiel), und das in gm oder local - wie gewünscht...

Gruss, Rolf

[wahsaga]

hi,

Der entscheidene Vorteil ergibt sich ME in der Scalierbarkeit der Darstellung eines Date-Formates ("%m.%d.%Y %H:%M" als Beispiel), und das in gm oder local - wie gewünscht...

das kann ich mit DATE_FORMAT() doch genauso haben, und zwar direkt im mysql-ergebnis, ohne überhaupt noch PHP bemühen zu müssen.

gruß,
wahsaga

[Rolf Rost]

hi again,

das kann ich mit DATE_FORMAT() doch genauso haben, und zwar direkt im mysql-ergebnis, ohne überhaupt noch PHP bemühen zu müssen.

Ok, mal was Anderes ;-)

ich hab eine Tabelle mit Aufträgen und darin einen Zeitstempel mit dem Zeitpunkt der Freigabe zur Bearbeitung. Im Laufe der Bearbeitung des Antrages wird dieser einer bestimmten Kategorie zugeordnet, die wiederum vom Aufwand abhängt (Entscheidung des Bearbeiters).

An dieser Kategorie hängt, notiert in einer anderen Tabelle, die Zeit in Arbeitstagen, was heißt, in wieviel Tagen der Antrag erledigt sein muss, Sonn- und Feiertage (Länderabhängig!) abgezogen. Stichzeit 14:00 Uhr. Irgendwann ist der Auftrag erledigt und der TS wird geschrieben.

Über diese ganze Geschichte soll nun ein Report erstellt werden... gibt es dazu Funktionen in MySQL die mir sowas abnehmen?

Gruss, Rolf

[Ilja]

yo,

Über diese ganze Geschichte soll nun ein Report erstellt werden... gibt es dazu Funktionen in MySQL die mir sowas abnehmen?

es gibt sicherlich funktionen, die mysql nicht kennt. aber ich denke mal, wahsagas aussage war, dass man nicht unötigerweise funktionen selbst erstellen muss, die mysql schon bereit stellt.

Ilja

[Rolf Rost]

Yoyo,

es gibt sicherlich funktionen, die mysql nicht kennt. aber ich denke mal, wahsagas aussage war, dass man nicht unötigerweise funktionen selbst erstellen muss, die mysql schon bereit stellt.

Das ist meine Aussage auch ;-)

Gruss, Rolf

[Ludger]

Hi,

Über diese ganze Geschichte soll nun ein Report erstellt werden... gibt es dazu Funktionen in MySQL die mir sowas abnehmen?

es gibt sicherlich funktionen, die mysql nicht kennt. aber ich denke mal, wahsagas aussage war, dass man nicht unötigerweise funktionen selbst erstellen muss, die mysql schon bereit stellt.

es ist immer eine schwierige Frage, ob man alles, was angeboten wird, auch nutzt. Beizeiten faellt vielleicht eine kleine Migration an, vielleicht auf ein anderes RDBMS, und der Mist ist nicht ANSI92 kompatibel. Da faellt mir eine huebsche Geschichte ein, als unsere VB-Leute mal ganz clever irgendwelche Windows-API Funktionsaufrufe eingebunden hatten und bei bestimmten Windows-Versionen (als Windows 2000 kam?) auf einmal nichts mehr ging. Oder die vielen huebschen Sachen, die mit T-SQL gehen, man aber m.E. nicht nutzen sollte.

Aber die Aussage "dass man nicht unötigerweise funktionen selbst erstellen muss, die mysql schon bereit stellt" ist schon richtig. Nur die Substanz dieser Aussage (Was ist unnoetigerweise? Ist vielleicht doch gemeint "alles nutzen, was MySQL hergibt"? Was bedeutet "muss" ganz genau?) ist etwas duenner, als, aeeeh, moeglich.

Gruss,
Ludger