nicht angemeldet
Hallo, Henryk!
Wenn du das Gefühl hast dein errechneter Timestamp würde danebenliegen dann ist das wahlweise ein Bug ein strtotime (das glaube ich aber nicht) oder du hast schon vorher einen Fehler. Was steht denn in $row['EndeZeit'] und wo kommt es her?
2004-11-02 21:31:22
das ist das format (datetime), das biet-o-matic in die mysql-datenbank schreibt.
und strtotime interpretiert das als gmt-datum, weil nichts zusätzlich angegeben ist und übernimmt damit mein lokales offset von +0100 .
ich könnte jetzt natürlich den zusatz recherchieren und von hand dazuschreiben. dann ist das script aber nicht mehr ohne änderung in anderen ländern einzusetzen. zum glück liefert mir Date("Z") aber das offset des rechners, auf dem das script ausgeführt wird, so dass ich den durch das fehlende zeitzonenkürzel entstandenen fehler wieder ausgleichen kann.
$timestamp = strtotime(1970-00-00 00:00:00) -> -1 (fehler bei der berechnung, da windows-system mit kaputter systembibliothek, siehe doku)
$timestamp = strtotime(1970-00-00 00:00:00 GMT) -> 0 (richtig)
$timestamp = strtotime(1970-00-00 01:00:00) -> 0 (richtig)
$timestamp = strtotime(1970-00-00 01:00:00 GMT) -> 3600 (richtig)
ich handle mir also mangels zeitzonen-kürzel 3600 sekunden fehler ein, die ich wieder abziehen muss, um auf den richtigen gmt-timestamp zu kommen.
Die ebay-Seiten geben soweit ich sehen kann korrekterweise zu allen Zeiten die Zeitzone an. Allerdings halt in der jeweiligen Landessprache (genau wie das Datum), was zumindest im Fall von Deutsch von strtotime nicht so gerne gefressen wird.
und biet-o-matic liest die nicht mit aus , sondern hat das für den server (.de, .co.uk, .com) jeweils gültige offset in stunden in der ServerStrings.ini stehen:
[DateTime]
;format
ansDateFormat="dd.mm.yy HH:mi:ss"
; Offset to UTC
ansOffsetLocal1=2
ansOffsetLocal2=1
vielen dank nochmal für deine hilfe. in zukunft werde ich damit keine probleme mehr haben, denke ich.
freundl. Grüsse aus Berlin, Raik