date(); geeft vreemd resultaat

Heel lelijk.

Ik weet natuurlijk niet precies wat je probeert te bereiken, maar het lijkt er een beetje op dat je een hoop gegevens uit de database haalt en dan in PHP gaat filteren wat je nodig hebt.
Dat is niet de manier, SQL is uitermate geschikt om gegevens te filteren.

Ik weet bijna zeker (ik ga uit van PHP 5.1 of hoger) dat je eerste creatie zal werken als je date_default_timezone_set('UTC'); bovenaan het script zet (of de date.timezone op UTC zet in php.ini).
Wat dus betekend dat het WEL een tijdzone probleem is =]

Het fijnste is om je database, PHP en zelfs de hardware clock van je server UTC te laten gebruiken en pas op het laatste moment (dat is bijna altijd wanneer je data gaat echoën) via de DateTime classe naar de gewenste timezone om te zetten.

Nu ben je met 82800 (23 * 60 * 60) en 85600 (24 * 60 * 60) aan het klooien wat goed gaat zolang PHP op een +1 timezone zoals Europe/Amsterdam ingesteld staat. In de winter tenminste...

UTC is de Coordinated Universal Time ("UTC" is een compromie tussen de engelse afkorting CUT en de franse afkorting TUC), en dus de perfecte tijdzone om te gebruiken bij het opslaan. Databases slaan het achter de schermen toch al op in UTC, maar als je een andere tijdzone insteld zal het telkens van en naar UTC converteren bij het ophalen en opslaan. Dus doe alles gewoon lekker in UTC tot je een andere tijdzone nodig hebt.

Edit: even iets toegevoegd na de onderstaande reactie.

ik vraag me ook af, of alles blijft werken zodra we weer overgaan op zomertijd.

Goed punt, ook daar is UTC er fijn omdat het niet aan Daylight Saving Time doet.

@Dos Moonen, het script begint met :
date_default_timezone_set('Europe/Amsterdam');
Ik kan me niet voorstellen dat het anders wordt als ik er UTC in zet in plaats van Europe/Amsterdam.

@Ger van Steenderen, het is een spel met kopen en verkopen.
Ik haal dus inderdaad alle producten van de gebruiker uit de database en laat ze zien.
Vervolgens bepaal ik met het verschil tussen de datetime uit de database en de servertijd of de producten weer verkocht mogen worden aan de bank.
Met strtotime kijk ik of de producten al 86400 seconden (24 uur) in het bezit zijn, dat is de lus:
$comparedate = time();
$dbDate = strtotime($datetimeuitdatabase]);

if ($dbDate + 86400 > $comparedate ){
// laat overgebleven tijd zien
}
else
{
//show button verkopen
}
Ik denk niet dat het uitmaakt of ik dat in de query doe want dan moet ik het resultaat van het tijdsverschil extra meegeven in de output.
De extra regel om de tijd te laten zien
$diff = 86400 - ($comparedate-$dbDate);
$diff is het aantal seconden dat nog te gaan is.

Aangezien timetostr() niet bestaat als omgekeerde van strtotime() ben ik gaan zoeken.
Op http://board.phpbuilder.com/showthread.php?10329970-time-to-str-possible werd deze oplossing gegeven.

echo date("Y-m-d H:i:s",$diff);

Maar daar zit dus een uur verschil tussen.
@Ivo P.
Ik denk niet dat het met daylight savings te maken heeft, want we zitten nu in wintertijd en dat is de echte tijd.

ik bedoel dan ook "werkt je patch van tel er een uur bij" nog steeds in de zomertijd, of moet het dan + 2 uur of +0 zijn.

Toen ik zei "bijna zeker" bedoelde ik ook echt "bijna zeker". Tenzij je PHP 5.0.5 of lager draait, want dan bestaat de functie niet, en zal het dus niet werken.
Het bewijs: http://3v4l.org/jSOqX

Het heeft dan weer niets met zomertijd te maken omdat unix timestamps 0 tot 86400 allemaal op 1 januari 1970 (UTC) vallen. Dat komt omdat een unix timestamp het aantal seconden sinds 1 januari 1970 UTC is. De date() functie verwacht een unix timestamp.
Wanneer wij aan wintertijd doen komt Europe/Amsterdam overeen met CET (Central European Time). CET loopt 60 minuten voor op UTC, 23:00 UTC is dus 00:00 CET.
Wanneer wij aan zomertijd doen komt Europe/Amsterdam overeen met CEST (Central European Summer Time). CEST loopt 120 minuten voor op UTC, 23:00 UTC is dus 01:00 CEST.
1 januari is voor zover ik weet voor geen enkele tijdzone de dag om over te gaan op zomertijd, dus zal je geen problemen tegenkomen wat betreft DST.

Als data in een datetime veld staat opgeslagen kun met een MySQL database via de (UNIX_TIMESTAMP(veldnaam) - CURRENT_TIMESTAMP()) AS seconds_left prima achterhalen hoeveel seconden er nog gewacht moet worden.

PS. ik realiseer me net dat ik de eerste was die het over tijdzones had ipv zomer/winter tijd. Dus mij "WEL" was niet helemaal gepast...

>> Als data in een datetime veld staat opgeslagen kun met een MySQL database via de (UNIX_TIMESTAMP(veldnaam) - CURRENT_TIMESTAMP()) AS seconds_left prima achterhalen hoeveel seconden er nog gewacht moet worden.

Dat kan zelfs nog simpeler:

SELECT
	IF(TIMESTAMPDIFF(HOUR, datetimecolumn, NOW()) >= 24, -1,
		TIMESTAMPDIFF(SECOND, datetimecolumn, NOW()) AS diff

Ik draai zelf WAMP met PHP 5.4.1 , mijn provider 5.3.3
UTC ipv Europe/amsterdam heb ik getest en levert hetzelfde probleem op.

Met seconds als output los ik het probleem niet op.
Het gaat juist om de functie date ()

Ik kan natuurlijk ook gewoon de seconds strippen tot uren en minuten, met een eigen functie maar dat is wel heel omslachtig.

[size=xsmall]Toevoeging op 04/02/2014 19:51:26:[/size]

edit op hierboven, het php file werd geinclude , in het bovenliggende document stond nog Europe/amsterdam .het lijkt nu toch te werken.

Timestampdiff in mysql rond naar beneden af.
Met bovenstaande query zou je vanuit het resultaat heel makkelijk kunnen bepalen of je een koop knop toont of het tijdsverschil laat zien:

<?php
if ($row['diff'] == -1) {
	//show button buy
}
else {
	echo date('H:i:s', $row['diff'])
}
?>