CMS Made Simple Forums

Hi
My server is in Amsterdam and I am in London.

Using PHP 5.3 you have to set the timezone to the servers location. Everything then works fine without the caching issues when trying to create new pages mentioned in threads like this: http://forum.cmsmadesimple.org/viewtopi ... t=timezone .

However, this means that all the news and calendar entries are all based on the wrong time zone.

I would just like to know if there is a way to override the time zone somehow, so that when my client creates a news story, the time is correct, or when a calendar event expires, it does so at the right time and not the server's timezone.

So far I have tried installing cmsms 1.9.4.2 under php5.3.5:
- Changing the timezone in the config.php causes caching issues when creating new pages.
- Adding SetEnv TZ :Europe/London in the .htaccess file also causes the caching problem.

The host (webfaction) suggested the .htaccess method but said Logically, the only way it wouldn't work, would be if it uses MySQL time as well. Unfortunately there is no easy solution if this is the case. Sadly it didn't help.

Can anyone shed any light on this - it seems a rather fundamental issue. I've been pulling my hair out, just trying to get a fresh install working in a way I'd be comfortable showing a client.

Regards

NikNak

Anyone?... CalGuy?

I've come to a complete halt!

Hi NikNak,

i am afraid there is no easy solution in your case, one way would be using EventManager to clear cache on specific events, probably with a UDT or something or you could have a look at ContentCache module, at least after quickly looking at it, it seems like you could be able clear cache on specific events.

Edit: Here is a small UDT from Rolf that could help you if you want to use EventManager http://forum.cmsmadesimple.org/viewtopi ... nt#p189980

Thanks Goran

Just knowing this is so helpful. I imagine it isn't just me with this issue.

The weirdest thing is that two other sites ported from UK servers to the Dutch php 5.3.5 server (including their UK timezone settings) are working fine - UK times are reflected in the back end. I tried to replicate this by doing a fresh install on the UK server and porting over in the same way - yet it didn't work this time! Oh joy

Thanks again - I will try the cache clearing UDT

Regards

Nik

Dear all,

I would like to chim in on that discussion. Unfortunately, it still does not work here. I tried everything I found in this and some other threads.

I did:
* Set the CMS timezone to "Europe/Zurich"
* Set php's default timezone to "Europe/Zurich"
* Set the server's timezone to "Europe/Zurich"

And it just doesn't work. I still have to clear cache manually. I even tried to leave the var in the configs of CMS empty, but didn't help neither. A restart of Apache2 didn't help neither.

I have PHP 5.3 and the newest version of CMS installed.

What's wrong?

Best,
Alex

And is it you or your server located in Europe/Zurich?
Look at this link http://forum.cmsmadesimple.org/viewtopi ... nt#p189980 that i already suggested to NikNak, then you can setup automated cache clearing which should solve your problem.

Yes, server's timezone is set to "Europe/Zurich" as well.
I tried your link, works pretty smoothly. Thanks.

[ Sorry all - this was an unrelated glitch ]

Sadly - this issue has cropped up again.

This time however, even with the cache clearing udt, the pages are displayed in the page list in the admin fine - but now - on the front end, no {content} is showing - unless a module is called or {get_template_vars} is within the {content} area!!

Here's how this stuff works (to the best of my knowledge):

a: The server has a timezone setting (not always easy to find).
b: PHP Has a Timezone Setting
- In PHP 5.3 if the timezone setting isn't set in the php.ini or by the api call date_default_timezone_set PHP 5.3 will spew all kinds of warnings on each and every call that deals with dates.
- Prior to PHP 5.3 it was an E_NOTICE
- CMSMS Has a config entry that used in to call date_default_timezone_set
c: MySQL may have timezone settings (ugh)
- which (in most circumstances, in an ideal world, should be the system timezone)
d: Any call to $db->DateFormat(time()); // used quite a bit in CMSMS and in tonnes of the modules will use the PHP timezone to format the unix timestamp (returned by time()) to a readable time string.
e: The readable time string is then stored in mysql.
f: Any call to $db->UnixTimeFormat('some date string') will use the PHP timezone to convert the string to a unix timestamp.
g: Any call to the MYSQL function NOW() will use mysql's timezone stuff... which (by default) should use the system timezone.
h: The PHP functions filemtime() and stat() return unix timestamps.
i: For performance reasons, CMSMS stores some data about the content tree into a static file in the tmp/cache directory. This is for a variety of reasons and must contain information about the entire treee.
j: Internally we know that most hosts use unix, and that unix filesystems store dates in timestamp format, which is seconds since the 'epoch', or '1970-01-01 00:00:00' UTC.
k: We know that 2:00AM (today) in Zurich is a different timestamp than 2:00 AM In the UK.

When a page is saved it's modification date is stored as a DATETIME value (see 'd' above).
When a page is loaded CMSMS does the following:

a: Gets the MAXIMIMUM date/time string from the modified date in the database and returns it as a UNIX TIMESTAMP
b: compares that generated UNIX TIMESTAMP to the filemtime of the contentcache.php
if the UNIX TIMESTAMP > the modification time of the contentcache.php the contentcache.php is generated
c: the cache is loaded
d: page generation continues

So lets go through the scenario of creating a new page when the server timezone is set to GMT and the PHP timezone is set to GMT+2 (hours). And lets say that the PHP time is (for convenience: 2:00AM).
ON PAGE SAVE:
- The System calls $db->DbTimeStamp(time()) and generates a string like 'OCT 17 2011 02:00:00'. This string is stored in the database.
ON PAGE LOAD (new page is in the navigation). This uses the PHP Timezone.
- The system finds the UNIX TIMESTAMP (using mysql timezone) of the modified date stored previously.
So we are using the PHP timezone to generate the datestamp before storing. Then the mysql timezone (which should be, but is not necessarily the system timezone) is used to generate a unix timestamp, which is then compared against a file modification timestamp. If those timestamps are NOT consistent, then the page may not appear immediately. Infact, for 2 hours in this example.

You may consider this to be a bug... I personally do not. CMSMS was never intended to be capable of having a 'presentation timezone' (or as a few people have asked multiple presentation timezones). And a separate database and/or system timezone. Infact in versions of PHP Prior to version 5 all timezones were assumed to be the same. This is still the case with CMSMS.

So, moral to the story is:
a: CMSMS only handles one timezone
b: Times are sometimes stored as date strings (which are timezone dependant). The content objects store time strings, other tables may store timestamps.
c: The web developer must ensure that the PHP timezone and the server timezone are one and the same... contact your host for the proper value if you are uncertain.

References:
http://php.net/manual/en/function.date- ... ne-set.php
http://dev.mysql.com/doc/refman/5.5/en/ ... pport.html
http://ca3.php.net/manual/en/function.filemtime.php
http://ca3.php.net/manual/en/function.date.php

NOTES (my personal $0.02):
Any UDT or plugin (or STUPID) module that clears the cache on each page request or page modification is not helping you, it is just masking a problem and decreasing performance. Infact, it's just the WRONG solution.

Thank you so much Robert for spending the time explaining this in so much detail - very helpful, I appreciate it.

So - in summary - the only way to have events and news stories that operate in your desired timezone is to have the host in the same country, (ie having the system set for that country).

Is this correct?

Kind regards

Nik

@calguy1000: Thanks for the detailed explanation!

Hmmm. Each MySQL client has its own timezone setting per-connection. So, I wonder if there is an easy way to get adodb[lite] to execute the MySQL statement to set the time_zone session variable after opening a new connection *but* before doing any work for CMSMS? Maybe a callback or somesuch? If so, then one *might* be able to synchronize all three timezone settings--using NikNak's timezone as an example:

Web server+CGI: .htaccess: SetEnv TZ Europe/London
PHP: e.g. .htaccess: php_value date.timezone Europe/London
MySQL: SQL: set time_zone = 'Europe/London';

Probably not something I would try on a production site, but it might be worth a little investigation in a safe development environment, as a possible feature enhancement.

...just a thought.

I have since discovered that my Host - Webfaction have the server I'm on set up with MySQL time set to Amsterdam and PHP time set to Texas. The server is in Amsterdam. I'm guessing this really doesn't help.

The host said: You can set the timezone in MySQL on a per-session basis as shown here:
http://stackoverflow.com/questions/1844 ... 8607#18607

Baring in mind that the above solution is unlikely to be implemented into cmsms, I'd still like to verify my earlier question, just to be sure I understand it correctly - the only way to have events and news stories that operate in your desired timezone is to have the host in the same country, (ie having PHP and MYSQL time set for that country).

Regards

Nik