[MySQL & PHP] Fout in de tijd?

[Funcracker]

Ik heb een server met daarop apache, mysql en php (nieuwste versies) en sites die daarop draaien lijken de indruk te geven dat de tijd 6 uur voorloopt.

Na wat onderzoek blijkt dat alles goed staat en de tijd op de srver goed staat maar websites vinden van niet..
Als ik een timestamp opsla in MySQL gaat dit goed.. De correcte tijd wordt weggeschreven als ik "now()" gebruik.

Het lijkt erop dat zodra ik in mijn query de tijd eruit haal met "UNIX_TIMESTAMP" ik 6 uur kwijtraak

Voorbeeld:

Het is 15:16:39
Ik voer een nieuwe entry in, in een table met daarin een timestamp field.
Timestamp na gesubmit te hebben:
"20030327151639"

In PHP voer ik de volgende query uit:
"SELECT UNIX_TIMESTAMP(timestamp) as time"

Output:
"1048774599"

Hier heb ik niets aan dus ik roep de PHP date functie aan om er iets van te maken:
date('Y-m-d H:i:s', '1048774599') // var even vervangen voor voorbeeld

Output:
"2003-03-27 09:16:39"

Hoe is dit mogelijk?

[drm]

ik weet niet weet hoe 't komt, maar je kunt allicht even kijken wat DATE_FORMAT er van maakt:

code:

SELECT
   DATE_FORMAT(`timestamp`,'%d-%m-%Y %H:%i:%s')
FROM
   `table`
WHERE
   #...

Maakt dat verschil?

imho is het sowieso beter voor dit soort dingen de MySQL functies te gebruiken ipv die van PHP, maar dat terzijde...

[.oisyn]

verkeerde zone setting? (GMT-5 zeg maar, EST dus)

[Rotjeknor]

Funcracker schreef op 27 March 2003 @ 15:59:
Het is 15:16:39
Ik voer een nieuwe entry in, in een table met daarin een timestamp field.
Timestamp na gesubmit te hebben:
"20030327151639"

Uhm, de echte timestamp ziet er niet zo uit?

In PHP voer ik de volgende query uit:
"SELECT UNIX_TIMESTAMP(timestamp) as time"

Als het als unix timestamp in de database staat, waarom doe je nog die conversie?

Output:
"1048774599"

Hier heb ik niets aan dus ik roep de PHP date functie aan om er iets van te maken:
date('Y-m-d H:i:s', '1048774599') // var even vervangen voor voorbeeld

Output:
"2003-03-27 09:16:39"

Hoe is dit mogelijk?

Mijn manier:
1. stop de huidige tijd als (echte) timestamp in de db
2. haal die eruit zonder conversie
3. converteer m met date

[.oisyn]

Rotjeknor schreef op 27 maart 2003 @ 16:09:
Uhm, de echte timestamp ziet er niet zo uit?

[...]

Als het als unix timestamp in de database staat, waarom doe je nog die conversie?

een mysql timestamp wordt weergegeven in het YYYYMMDDHHMMSS formaat, vandaar dat ze er verschillend uitzien, en vandaar dat er een functie is om m naar unix timestamp om te zetten

[ Voor 9% gewijzigd door .oisyn op 27-03-2003 16:15 ]

[Funcracker]

drm schreef op 27 maart 2003 @ 16:08:
ik weet niet weet hoe 't komt, maar je kunt allicht even kijken wat DATE_FORMAT er van maakt:

code:

SELECT
   DATE_FORMAT(`timestamp`,'%d-%m-%Y %H:%i:%s')
FROM
   `table`
WHERE
   #...

Maakt dat verschil?

imho is het sowieso beter voor dit soort dingen de MySQL functies te gebruiken ipv die van PHP, maar dat terzijde...

Dit werkt wel goed. Niet geprobeerd idd, maar aangezien de timestamp er wel goed instaat in eerste instantie was dit wel te verwachten.. Dit is misschien wel een betere manier, maar ik wil eigenlijk dit probleem oplossen

.oisyn schreef op 27 maart 2003 @ 16:08:
verkeerde zone setting? (GMT-5 zeg maar, EST dus)

Waar zou ik die setting in kunnen stellen?

Rotjeknor schreef op 27 maart 2003 @ 16:09:
[...]

Uhm, de echte timestamp ziet er niet zo uit?

[...]

Als het als unix timestamp in de database staat, waarom doe je nog die conversie?

[...]

Mijn manier:
1. stop de huidige tijd als (echte) timestamp in de db
2. haal die eruit zonder conversie
3. converteer m met date

Dit is een MySQL timestamp die uit de MySQL functie "now()" komt rollen.. Is eigenlijk een gestripte datetime.

En er staat dus geen unix timestamp in, dus vandaar de conversie.
Jou manier is ook goed, maar ik wil snappen hoe dit kan..

Zodra ik convert gaat het opeens verkeerd? Hoe is dat mogelijk?

edit: .oisyn was iets eerder

[ Voor 3% gewijzigd door Funcracker op 27-03-2003 16:18 ]

[.oisyn]

Funcracker schreef op 27 maart 2003 @ 16:17:
Waar zou ik die setting in kunnen stellen?

er wordt meestal gewoon gebruik gemaakt van de locale settings van je OS. Dus is je server wel goed ingesteld?

[Funcracker]

.oisyn schreef op 27 March 2003 @ 16:30:

[...]


er wordt meestal gewoon gebruik gemaakt van de locale settings van je OS. Dus is je server wel goed ingesteld?

Yupz.. Zoals al in eerste post gemeld loopt die tijd goed.

Rare is dus dat als ik mijn tijd invoer in MySQL het ook goed gaat..
Alleen niet zodra ik hem convert en eruit haal..

[.oisyn]

Dat de tijd goed loopt wil nog niet zeggen dat je zone settings goed staan. Ik kan deze pc ook wel op 16:33 zetten maar dan GMT-5

De tijd loopt dan goed, maar van de timestamps klopt dan geen zak meer (die zijn altijd GMT, en zonder daylight-savings-time)

[Funcracker]

.oisyn schreef op 27 March 2003 @ 16:34:
Dat de tijd goed loopt wil nog niet zeggen dat je zone settings goed staan. Ik kan deze pc ook wel op 16:33 zetten maar dan GMT-5

De tijd loopt dan goed, maar van de timestamps klopt dan geen zak meer (die zijn altijd GMT, en zonder daylight-savings-time)

Sorry, mijn fout..
Die staat ook goed.. Staat op GMT+1.

Na wat nader onderzoek blijkt dat de timestamp in PHP verkeerd staat.. Die staat op US Eastern wat de 6 uur precies verklaard.. Volgens mijn info haalt PHP echter zijn timezone info op via Apache uit de OS..

Ik ga er dus nu vanuit dat die date functie van PHP mijn UNIX timestamp dus parsed naar US Eastern tijd..

Dit maakt het bijna nog onlogischer..

[.oisyn]

mwoa niet onlogischer, het is een goede verklaring
de vraag is idd alleen hoe php aan die rare setting komt... Is er soms een environment variabele met de naam LC_ALL, LC_TIME of LANG?

[Funcracker]

.oisyn schreef op 27 March 2003 @ 16:56:
mwoa niet onlogischer, het is een goede verklaring
de vraag is idd alleen hoe php aan die rare setting komt... Is er soms een environment variabele met de naam LC_ALL, LC_TIME of LANG?

De eerst twee komen niet voor.. LANG wel:

LANG: en_US
TZ: US/Eastern

In LANG schuilt toch geen probleem?

Thnx voor de hulp sofar in ieder geval

[.oisyn]

ja, daar zit dus wel het probleem. Als je naar de documentatie van de php-functie setlocale () kijkt dan zie je dat ie standaard LANG pakt als locale. Over TZ zie ik zo snel niet iets, maar dat heeft er ongetwijfeld ook mee te maken. Wie zet deze vars? En waarom zijn ze zo gezet als je de timezone gewoon op GMT+1 hebt ingesteld?

.edit: je kunt net natuurlijk oplossen door aan je begin van je script dit te zetten:

PHP:

setlocale (LC_TIME, "nl_NL");

maar netter is om die timezone settings echt goed te krijgen

[ Voor 23% gewijzigd door .oisyn op 27-03-2003 17:10 ]

[Funcracker]

.oisyn schreef op 27 maart 2003 @ 17:08:
ja, daar zit dus wel het probleem. Als je naar de documentatie van de php-functie setlocale () kijkt dan zie je dat ie standaard LANG pakt als locale. Over TZ zie ik zo snel niet iets, maar dat heeft er ongetwijfeld ook mee te maken. Wie zet deze vars? En waarom zijn ze zo gezet als je de timezone gewoon op GMT+1 hebt ingesteld?

.edit: je kunt net natuurlijk oplossen door aan je begin van je script dit te zetten:

PHP:

setlocale (LC_TIME, "nl_NL");

maar netter is om die timezone settings echt goed te krijgen

Die setlocale optie verandert helaas niets als ik hem bovenaan mijn script zet..
Waarom die LANG optie zo staat weet ik niet.. Maar opzich wel logisch toch.. We hebben geen Nederlandse Linux distributie ofzo..?
(of zeg ik nu iets heel stoms:?)

[.oisyn]

Daar heb je idd gelijk in, maar het blijft raar dat de timezone nog steeds op US/Eastern staat.
Waarom die setlocale () oplossing niet werkt weet ik eigenlijk niet

[Funcracker]

.oisyn schreef op 27 March 2003 @ 17:33:
Daar heb je idd gelijk in, maar het blijft raar dat de timezone nog steeds op US/Eastern staat.
Waarom die setlocale () oplossing niet werkt weet ik eigenlijk niet

Yupz..
En waarom werkt het in MySQL wel goed.. die maakt voor zover ik weet ook gebruik van de time en timezone van het systeem.

* Funcracker is puzzled..

[Verwijderd]

OM de eerste post van Funcracker in dit topic even aan te vullen: Het gaat om 2 servers. Een webserver, waar het probleem zich voordoet, en een databaseserver. In prinicpe had het hele mysql verhaal mogen worden weggelaten.

Het is echt PHP die op de een of andere vage manier blijft volhouden dat de TZ. US/Eastern is ipv EUROPE/Amsterdam, terwijl de server wel zo staat ingevuld.

[.oisyn]

is er ergens misschien iets mis in de php.ini of een van de apache config files (httpd.conf, .htaccess, ...)?

[Funcracker]

Verwijderd schreef op 27 March 2003 @ 17:51:
OM de eerste post van Funcracker in dit topic even aan te vullen: Het gaat om 2 servers. Een webserver, waar het probleem zich voordoet, en een databaseserver. In prinicpe had het hele mysql verhaal mogen worden weggelaten.

Het is echt PHP die op de een of andere vage manier blijft volhouden dat de TZ. US/Eastern is ipv EUROPE/Amsterdam, terwijl de server wel zo staat ingevuld.

Dat het niets met MySQL te maken had kwam ik dus ook achter

Even voor de duidelijkheid: Ik heb onze system admin even op deze topic gewezen aangezien ik ga feesten zo

Dit is mijn laatste post in deze kwestie, dus ik hoop dat iemand Trebel verder kan helpen..
Thnx voor de hulp tot nu toe!

[Verwijderd]

.oisyn schreef op 27 March 2003 @ 17:54:
is er ergens misschien iets mis in de php.ini of een van de apache config files (httpd.conf, .htaccess, ...)?

geen .htaccess aanwezig en zover ik heb kunnen vinden kun je dit helemaal niet instellen in je php.ini of httpd.conf. Daarom vind ik het zo raar