Timestamp

[aKraus]

Hallo,

Ich verzweifle derzeit an folgenden Problem:
Es existiert eine Tabelle mit deinem Feld vom Type Timestamp. Jetzt will ich per SYSDATE() das akutelle Datum reinschreiben. Allerdings entspricht der Wert dieses Feldes danach nicht die Anzahl der Sekunden seit dem 1.1.1970 sondern z.B. 20050713070249 <== also einfach das aktuelle Datum.

Wenn ich jetzt beispielsweise hergehe und eine Zahl reinschreibe, wird in diesen Feld nur eine ganze Armee von Nullen angezeigt.

Woran kann das liegen?

P.S. Ich will kein Feld DateTime oder so ähnlich, da ich den Timestamp im PHP Code formatieren müsste...

Greatz

 

[hpvw]

Hallo,

Ich verzweifle derzeit an folgenden Problem:
Es existiert eine Tabelle mit deinem Feld vom Type Timestamp. Jetzt will ich per SYSDATE() das akutelle Datum reinschreiben. Allerdings entspricht der Wert dieses Feldes danach nicht die Anzahl der Sekunden seit dem 1.1.1970 sondern z.B. 20050713070249 <== also einfach das aktuelle Datum.

Wenn ich jetzt beispielsweise hergehe und eine Zahl reinschreibe, wird in diesen Feld nur eine ganze Armee von Nullen angezeigt.

Woran kann das liegen?

Wenn Du die MySQL-Funktion SYSDATE meinst, so hat diese nichts mit einem Unix-Timestamp zu tun.
In MySQL gibt es nur Funktionen zum Konvertieren, aber keine Funktionen zum erzeugen und keinen speziellen Feldtyp, um Unix-Timestamps zu speichern. Du musst einen INT oder BIGINT verwenden.

P.S. Ich will kein Feld DateTime oder so ähnlich, da ich den Timestamp im PHP Code formatieren müsste...

Das ist kein Argument, da MySQL auch einen Unix-Timestamp einlesen und zurückgeben kann und ebenfalls etliche Datums- und Zeit-Funktionen zur Formatierung bietet. In einem anderen Thread wurde ausgiebig über die Vor- und Nachteile diskutiert.

Gruß hpvw

 

[aKraus]

Wenn Du die MySQL-Funktion SYSDATE meinst, so hat diese nichts mit einem Unix-Timestamp zu tun.
In MySQL gibt es nur Funktionen zum Konvertieren, aber keine Funktionen zum erzeugen und keinen speziellen Feldtyp, um Unix-Timestamps zu speichern. Du musst einen INT oder BIGINT verwenden.

mit welcher Function schreib ich denn dann die akutellen UNIX Timestamp in dieses Feld?

Das ist kein Argument, da MySQL auch einen Unix-Timestamp einlesen und zurückgeben kann und ebenfalls etliche Datums- und Zeit-Funktionen zur Formatierung bietet. In einem anderen Thread wurde ausgiebig über die Vor- und Nachteile diskutiert.

Ich möchte jetzt beispielsweise die bereits vergangenge Zeit anzeigen. etwas 3min oder 5h oder 2d oder 12w oder 3y. Sag mir bitte, wie ich dies deiner Meinung in einen Select am besten formatiere? In PHP mach ich das ganz einfach in einer Funktion...

 

[hpvw]

mit welcher Function schreib ich denn dann die akutellen UNIX Timestamp in dieses Feld?

UNIX_TIMESTAMP(NOW())

Ich möchte jetzt beispielsweise die bereits vergangenge Zeit anzeigen. etwas 3min oder 5h oder 2d oder 12w oder 3y. Sag mir bitte, wie ich dies deiner Meinung in einen Select am besten formatiere? In PHP mach ich das ganz einfach in einer Funktion...

Mit DATE_FORMAT kannst Du es nach Deinen Wünschen formatieren. Ich glaube, die Formatierungssyntax ist sogar mit der von [phpf]date[/phpf] in PHP gleich.
Wenn Du auf ganz spezielle Weise "runden" willst, benötigst Du, wie in PHP auch, eine IF-Kontrollstruktur.
Dazu gibt es noch die Funktionen WEEK, YEAR, TO_DAYS, HOUR etc.

Gruß hpvw

 

[aKraus]

wie ichs formatiere ist mir schon klar. jetzt arbeite ich aber mit Multi Language und da wird in jeder Sprache das Datum anders formatiert... Des weiteren würde ein select, welcher mir das zurückbringt so wie ich es haben will verdammt unperformant sein (mit den ganzen if).
Glaubs mir, in meinem Fall geht es in einer PHP Funktion wesentlich schneller...

Trotzdem danke für den Timestamp

So Long

 

[hpvw]

Ich würde mir an Deiner Stelle trotzdem den kleinen Performanceverlust gönnen und das Feld semantisch korrekt als DATETIME deklarieren. Damit zu arbeiten ist nicht weiter schwer:

Aktuelle Zeit einfügen:

... SET spalte=NOW() ...

Zeit von einem Unix-Timestamp aus PHP eintragen:

... SET spalte=FROM_UNIXTIME(<der Timestamp aus PHP>) ...

Auslesen, um in PHP mit Unix-Timestamp weiterzuarbeiten:

SELECT ... UNIX_TIMESTAMP(spalte) AS `utsdatum` ...

Gruß hpvw

 

[aKraus]

so ungefähr wird meine Funktion in PHP ausgesehen (ungetestet). Ich glaube nicht, dass du sowas in SQL besser hinbekommst...

 function GetAge($val) {
		$now  = time();
		$diff = $now - $val;
		if($now < $val) {
			return 'future...';
		}
		
		if($diff > 31104000) { //year
		 return date('y', $diff).'Years';
				  
		} elseif($diff > 2592000) {
		 return date('n', $diff)'Months'; 
				 
		} elseif($diff > 86400) { //day
		 return date('d', $diff)'Days';  
				
		} elseif($diff > 3600) { //hours
		 return date('G', $diff)'Hours'; 
				 
		} else {
		 return date('i', $diff)'Minutes'; 
				 
		}
	}

 

[hpvw]

Juhu, eine Herausforderung:

SELECT 
`zeit` AS `gespeicherte Zeit`,
NOW() AS `jetzt`,
if (NOW()<`zeit`
    ,'Zukunft'
    , if (DATE_ADD(`zeit`, INTERVAL 1 YEAR)>NOW()
        ,if (DATE_ADD(`zeit`, INTERVAL 1 MONTH)>NOW()
            ,if (DATE_ADD(`zeit`, INTERVAL 1 DAY)>NOW()
                ,if (DATE_ADD(`zeit`, INTERVAL 1 HOUR)>NOW()
                    ,CONCAT(if (MINUTE(NOW())<MINUTE(`zeit`),60,0)+MINUTE(NOW())-MINUTE(`zeit`),' Minuten')
                    ,CONCAT(if (HOUR(NOW())<HOUR(`zeit`),24,0)+HOUR(NOW())-HOUR(`zeit`),' Stunden')
                )
                ,CONCAT(if (MONTH(NOW())<MONTH(`zeit`)
                           ,DAYOFMONTH(DATE_SUB(NOW(),INTERVAL DAYOFMONTH(NOW()) DAY))
                           ,0)
                    +DAYOFYEAR(NOW())-DAYOFYEAR(`zeit`)
                    ,' Tage')
            )
            ,CONCAT(if (MONTH(NOW())<MONTH(`zeit`),12,0)+MONTH(NOW())-MONTH(`zeit`),' Monate')
        )
        ,CONCAT(YEAR(NOW())-YEAR(`zeit`),' Jahre')
    )
) AS `Alter`
FROM daten
ORDER BY `gespeicherte Zeit`

Kann sein, dass es irgendwo noch geringfügiges Fehlverhalten gibt, aber vom Prinzip her sollte es sich auf diese Weise lösen lassen.
Wenn es überwiegend mehrere Jahre sind, kann ich mir vorstellen, dass das Query sogar relativ performant ist. Ich habe heute Abend aber keine große Lust, noch einen Performancetest durchzuführen. Daher kann ich "besser" in Bezug auf die Performance nicht beurteilen, aber es ist in jedem Fall bezüglich des verwendeten Datentyps besser, als einen Zeitpunkt als Ganzzahl abzulegen.
Das ist mir auf jeden Fall wichtiger, als die Performance. Wenn ein Query im Vergleich zur Anwendungssprache (PHP, Jave, etc.) absolut inperformant wird, greife ich auf die Methode zurück, die ich im sechsten Post beschrieben habe. Damit bleibt mir der Datentyp erhalten und ich kann in der Anwendungssprache mit dem Unix-Timestamp arbeiten.

Gruß hpvw