Datum?

Sag ich doch un der in Amerika hat leider die falschen Daten, und der in Japan auch. Da bringt dir die schreibweise auch nix! Soweit müssen wir auch nicht reisen. Reicht nach Greichenland schon stimmt das ding nicht mehr!
Bei einer Zeitverschiebung haben wir ein Problem .

Sag ich doch erst überlegen!

Grüsse

aber wir lassen die Disskusion lieber bleiben!
 
Lukasz hat gesagt.:
Siehst du da ist schon das Problem (du gibst es formaiter aus) und dies soll ich glauben?

Geschrieben am 2004-11-28 von ... echt?

Bei mir sieht das so aus
http://www.2ts2.net/index.php?&get=forum/showpost.php&thisthread_id=514&seite=10000000

Sorry ich will dich nicht angreifen man kann die Reihenfole auch drehen. Aber verate mir mal dann wie schnell du Daten von gestern zwischen 14-15 Uhr auslesen kannst, und das ganze auch noch vorwärst geordnet. Genau das meinte ich. Erst sollt man überlegen.
Poste jetzt aber nich ein SQL Befehl, denn dieser formatiert ja schon!

Grüsse!

PS du formatierst ja auch 2 mal MYSQL bei der Eingabe von mir aus automatisch und dann mit SQL bei der Ausgabe. Macht keinen Sinn, ausser du willst das auch in EXEL ó.ä. bearbeiten.

Möchtest du einen Text auf deutsch ausgeben wie "Am 20 November" so formatierst du das dritte mal wo ich das erste mal ansetze!

Und noch ein Dritter Grund: Wenn einer aus Amerika postet hast du den deutschen Zeitstempel, oder denn den der Server hat. Mit einem Binären kannst du praktisch auf die Amerkianische Zeit umrechnen. Wieder ein Nachteil was MYSQL mit sich bringt!
Zum Vergrößern anklicken....


oO schön für dich dasa du da schreibst: " Am xy November" nur das mein lieber schreiben nun wirklich verdammt wenige. Schön da schreib ich mir halt mal ne kurze Funktion dazu ansonsten ist es wesentlich einfacher per SQL. nenbenbei schon mal gezählt was es für ein Aufwand ist, mit PHP aus nem Timestamp 16.12.2004 zu erhalten und mit sql? Und was übersichtlicher ist? Nebenbei darf ich da auch noch das Datum abfangen was mir bei der Foramtierung mit SQL erspart bleibt.
 
Lukasz hat gesagt.:
Sag ich doch un der in Amerika hat leider die falschen Daten, und der in Japan auch. Da bringt dir die schreibweise auch nix!

Sag ich doch erst überlegen!

Grüsse

aber wir lassen die Disskusion lieber bleiben!
Zum Vergrößern anklicken....

Hallo? Welche falschen Daten? Is doch klar dass ich das entsprechend sage Monat Jahr etc. wenn jemand suchen will. Ansonsten is das eine Formatierungstechnische Frage. Aber egal bei dir darf sich ja der Japaner mit November rumschlagen ist ja viiiiiiiiel besser -.-
 
ein riesen Problem?

<?php
$morgen = mktime(0, 0, 0, date("m") , date("d")+1, date("Y"));
$letztermonat = mktime(0, 0, 0, date("m")-1, date("d"), date("Y"));
$naechstesjahr = mktime(0, 0, 0, date("m"), date("d"), date("Y")+1);
?>

SELECT * FROM WHERE datum < mktime()...

Und die Funktion spar ich mir.
Sag ich doch erst überlegen...

http://de.php.net/date
 
Zuletzt bearbeitet von einem Moderator:
TheLightning hat gesagt.:
Schaut mal bitte auf

http://dev.mysql.com/doc/mysql/de/Date_and_time_functions.html

unter UNIX_TIMESTAMP()

DANN können wir weiterreden wegen umformatiertung... für PHP macht es KEINEN unterschied.... nur für MySQL und für den Query

MfG Dominik ;)
Zum Vergrößern anklicken....

Aber genau darum geht es doch! Natürlich macht es für php was. Ohmanoman.... PHP rechnet sicher nicht mit daten wie 2004-11-28! Der SQL Befehl rechnet diesen auch erst aus. Sonst wirde ja in der DB ein Zeitstempel gespeichert, und der dann nur als 2004-11-28 angezeigt. Wer mal exportiert der weis das dem nicht so ist. Und wer nicht eis was zum Beispiel while($row=mysql.... bedeutet dem kann ich auch nicht helfen!

Aber ich halte mich raus. Jeder wie er es will!
 
Zuletzt bearbeitet von einem Moderator:
@Lukas mir reichts jetzt! Zeitverschiebung? Das Problem hast du beim Timestamp genauso. Deine Argumente sind bis jetzt teilweise falsch oder einfach nicht haltbar. Informier dich erstmal was MYSql kann und schau dir mal die Seiten an was wirklich benötigt wird und du wirst feststellen, dass die Datumsformatierung mit Mysql schneller und einfacher geht.

Und dann können wir gerne wieder weiterreden...
 
es gibt nicht nur mktime() ist nur ein Baeipiel. Aber ich las dich in deinem Glauben leben!
Aber noch ein Tipp: Kauf dir das PHP Buch

- PHP 5 & MYSQL 4 Praxisbuch von Herrn Kannengiesser! Da steht extra ein Artikle drin warum man es nicht machen sollte!

Leider hab ich jetzt nicht vor mir sonst würde ich dir den Artikel posten. Es liegt bei mir zu Hause im Schrank!

Aber wenn dem so ist werde ich mich nachträglich darum mühen. Ich kann dir aber aus dem Gedächtniss sagen, dass es so ist. Vieleicht hat einer von euch das Buch vor sich liegen und schaut dort unter Datum und Zeitfunktionen. Glaube Seite 215 hatte es letztens erst. Dort ist da beschrieben mit Zeitverschiebung etc. und warum es so Sinn macht!

Ich denke Fehler sind menschlich aber dieses mal haben wir eben mal eine Meinungsverschiedenheit. Aber das macht nichts und kommt schon mal vor. Du selbst musst wissen wie du deine DB bestückst. Aber kommt mal wieder auf dem Boden zurück. Wäre besser ihm zu helfen!
 
Zuletzt bearbeitet von einem Moderator:
So, jetzt muss ich mich auch mal wieder einschalten.

@Lukasz: Wer keine Ahnung hat, lieber mal die Klappe halten.
Das was du in deinen Beiträgen schreibst, ist absoluter Schwachsinn und schlichtweg falsch.

Zur Performance-Frage: Ich hab grad mal nen kleinen Benchmark gemacht, zum Vergleich von DATE und INT.

Beim Eintragen des aktuellen Datums:
PHP: 
mysql_query('INSERT INTO `date1` (`date`) VALUES ('.time().')');
mysql_query('INSERT INTO `date2` (`date`) VALUES (NOW())');
Das ganze in einer for-Schleife 20000 mal ausgeführt. Ergebins (die obere Zahl ist immer die INT-Tabelle, die untere die DATE-Tabelle, Angaben in Sekunden)
Code: 
INSERT 20000

4.69330501556
4.56666183472

4.651293993
4.77843022346

4.87074017525
4.56725287437

4.56100606918
4.63716387749

5.39655685425
4.93879318237

4.25709199905
4.43373703957

4.84162306786
5.06249403954

5.07062602043
4.60275888443

Beide schenken sich nix. Kein wirklicher Performance-Unterschied festzustellen.


Beim Auslesen des Timestamps (100000 Einträge):
PHP: 
$q = mysql_query('SELECT `date` FROM `date1` LIMIT 100000');
$q = mysql_query('SELECT UNIX_TIMESTAMP(`date`) FROM `date2` LIMIT 100000');

Code: 
QUERY 100000

1.09772515297
1.3052740097

1.15474104881
1.35974884033

1.45250487328
1.49005413055

1.27556490898
1.46494698524

1.42596292496
1.59173893929

1.2312541008
1.54599785805

1.23264503479
1.46512103081

1.35339689255
1.4985370636

Hier ein leichter Performance-Vorteil für INT.

Beim Auslesen eines formatieren Datums (Format: Tag.Monat.Jahr, 100000 Einträge):
PHP: 
$q = mysql_query('SELECT `date` FROM `date1` LIMIT 100000');
while($r = mysql_fetch_assoc($q))
{
	$t = date('d.m.Y', $r['date']);
}

$q = mysql_query('SELECT DATE_FORMAT(`date`, \'%d.%m.%Y\') AS `date` FROM `date2` LIMIT 100000');
while($r = mysql_fetch_assoc($q))
{
	$t = $r['date'];
}

Code: 
QUERY 100000 FORMATED

1.74949097633
1.40209102631

2.13595604897
1.36897110939

2.06497788429
1.68517589569

2.04752182961
1.57983899117

1.83439803123
1.79203891754

1.82310986519
1.60400295258

2.07666921616
1.80233812332

2.05949783325
1.54520893097

1.79287195206
1.68496394157

Hier ein leichter Performance-Vorteil für DATE.

Alles in allem schenken sich die 2 Möglichkeiten nicht viel. Performance-Technisch ist es deswegen irrelevant, wie man die Daten speichert.
 
Hab den Benchmark nun nochmals auch mit DATETIME gemacht. Hier die Ergebnisse:

Eintragen: (erste Zeile INT, zweite Zeile DATE, dritte Zeile DATETIME)
Code: 
INSERT 20000

4.69330501556
4.56666183472
4.46113204956

4.651293993
4.77843022346
5.08389806747

4.87074017525
4.56725287437
4.60454392433

4.56100606918
4.63716387749
4.47782993317

5.39655685425
4.93879318237
4.8088490963

4.25709199905
4.43373703957
4.42622494698

4.84162306786
5.06249403954
4.31641602516

5.07062602043
4.60275888443
4.62859392166

Beim Eintragen ist es also absolut egal.

Beim Auslesen des Timestamps:
Code: 
QUERY 100000

1.1609120369
1.45223712921
1.39744710922

1.2569258213
1.5901350975
1.4830789566

1.07843089104
1.25645589828
1.36100506783

1.260668993
1.51001095772
1.36932897568

1.08475494385
1.37932610512
1.30494785309

1.11266613007
1.37767982483
1.3613679409

1.14749789238
1.33583307266
1.41229510307

1.10987401009
1.40876507759
1.30276894569

INT hat wieder leicht die Nase vorn, DATE und DATETIME schenken sich praktisch nichts.

Beim Auslesen des formatierten Datums (erste Zeile INT, zweite Zeile DATETIME, Format: d.m.Y H:i:s);
Code: 
QUERY 10000 FORMATED DATETIME

2.21133995056
4.18734383583

2.2957470417
4.28385806084

1.99954295158
3.62903499603

2.20496416092
4.16135811806

1.89528298378
3.54531788826

1.91541194916
3.58165192604

2.05247998238
3.69539785385

1.93139791489
3.62061190605

In diesem Fall hat INT deutlich die Nase vorn, und braucht nur knapp halbso lang, wie DATETIME.
Noch zu erwähnen, den Datenspeicher, die die 3 Formate brauchen:
INT: 4 Byte
DATE: 3 Byte
DATETIME 8 Byte
(Angaben laut http://dev.mysql.com/doc/mysql/de/Storage_requirements.html)

Fazit: Wenn es auf Performance ankommt, und man die Beschränkung vom 1.1.1970 und ?.?.2037 hinnehmen kann, ist INT eindeutig die bessere Alternative, wenn es darum geht, mehrere Tausend Datensätze abzufragen.
Für Otto-Normalverbraucher, der keine Datenbank mit mehreren Terra-Byte Daten hat, ist der Performance-Unterschied nicht spürbar.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück