Thread

Problem: Entry date incorrect by one hour

Entries do not appear on the website despite the system time passing the entry date value.

We’ve run into this issue a couple of times and have been unable to resolve this by adjusting server settings or localisation settings; Toggling the DST setting and adjusting the server offset value has no effect.

We’ve found that setting the entry date to one hour in the past resolves this issue.

Please advise.

Hi madebycloud,

Many things factor into how ExpressionEngine determines an entries date.

ExpressionEngine itself:
The server needs to have the timezone properly set at the system level and in php.ini
In the Control Panel, Admin-> Localization Settings: The “Server Time Zone” should match the server’s own settings and DST should be enabled if in effect. “Server Offset (in minutes)” can be left alone in almost every case.

Then, a member’s own localization settings are applied. If you are logged into the Control Panel or the front-end, or logged into the Control Panel and viewing the front-end then the entry date reflects your members localization settings under My Account-> Localization Settings.

In this instance, say your server is in the US West Coast (UTC -8) and you are in the US East Cost (UTC -5). If you are logged into the Control Panel or the front-end of a member site, entry dates will be affected by your local time, off by 3 hours.

For instance, you make an entry in UTC -5 and it is 8PM. The entry is published, you see it on the front of the site and all is well. You log out of the Control Panel, or a random visitor sees the site - the server is in UTC -8 and it is only 5PM there, the entry appears to not be published.

If you are logged out, entry dates will reflect the system’s time, off by 3 hours in the other direction - so to speak. Any visitors to the site are presented with the system’s timezone.

Member settings can be forced to honor ExpressionEngine system settings, but if users can set their own, they should reflect the users local timezone and DST customs.

You can force members to use the system’s time by going to Members-> Preferences: Allow members to set their own localization preferences? set to “No”.

I hope that helps clarify and gives you some ideas how to manage localization in ExpressionEngine.

~

Thanks for the thorough response, Dan!

We’re in London so everything is set to GMT for us (server, EE and members). It’s also apparent in our local MAMP environment.

Do you have any suggestions on troubleshooting this?

Hey madebycloud,

We’re in London so everything is set to GMT for us (server, EE and members).

Well - hrm - Everything should be good then. The timestamp ExpressionEngine applies to entries is GMT.

Perhaps a closer look? Be on the lookout for an email from EllisLab!

In the meantime, verify as much as you can regarding the timezones for ExpressionEngine, the Server and a Super Admin account, including the correct setting for DST in your location.

Thanks!

Hi Guys,

I noticed a similar problem since I upgraded to 2.5.2.
An entry with a publication date set to 10:15 will only be published in the front-end at 12:15.

The admin is DST: No, timezone: UTC+1, and localisation settings are configured with the same settings.

So I tried something, I just output the time on a page with:

{current_time format="%h:%i"}

At 11:50, the output was 9:50…

So, I tried to change a few Localisation settings. First, the time zone: no effect. Then the DST, set to Yes: no effect. Then I added 120 to Offset, and finally had a correct result.

This is probably the fourth thread I post about timezone and DST problems. I thought it was solved…

Cheers,

Pv

Hi Pv Ledoux,

Your test shows that the server seems to be 2 hours behind. Can you verify with the host that the server’s time and time-zone are configured both in the system’s settings and in PHP?

An Offset of 120 minutes is a sign something isn’t right deeper than ExpressionEngine.

Cheers,

I’ve just upgraded an EE1 website to EE 2.5.3 and I have also noticed a -1 hour difference in the timestamp generated by ExpressionEngine.

Using config overrides, the Server Time Zone is set to UTC; Default Time Formatting is set to European and Daylight Saving Time is set to Yes.

I have also set:

$config['allow_member_localization']  = 'n';

I’ve tested this on a local MAMP installation and a remote server (both located in the UK).

I have compared the date stamp using {current_time} and PHP’s date() function.

date('Y-m-d g:i | Z | P | I | T')

2012-10-13 1:38 | 3600 | +01:00 | 1 | BST

and

{current_time format="%Y-%m-%d %g:%i | %Z | %Q | %I | %T"}

2012-10-13 12:38 | 3600 | +00:00 | 1 | GMT

As you can see, the Difference to Greenwich time (GMT) differs by an hour.

Any ideas why EE would create this discrepancy?

It’s a major blow as the site I’ve upgraded is for a Theatre and the entries are dependent on the correct date.

I am no PHP expert, but I will look at the core files to see if I can the cause of this bug.

Okay. I can offer a little more insight, but not a solution at this stage.

The function set_localized_time() is being called within libraries > Localize.php but it appears the $dst value is never been passed to it, not at least within the Localize.php file.

This means that on line 209 the following conditional is invoked:

if ($dst == '')
     {
          $dst = $this->EE->session->userdata('daylight_savings');
     }

And the following conditional on link 214 is being ignored:

if ($dst == 'y')
     {
          $now += 3600;
     }

Although it should have no effect, as I have set the following:

$config['allow_member_localization'] = 'n';

The following has a value of n:

$this->EE->session->userdata('daylight_savings');

I’ve checked my settings within the account and I can confirm this is set to you. Therefore, I am wondering if the problem lies with the membership module.

I’ve managed to find a temporary fix for this problem by adding the folliowing to my config.php file:

$config['default_site_dst']      = 'y'; # (y/n)

It’s less than ideal as I would prefer to let my client have control over the DST settings, so a permanent fix would be preferable.

I don’t know how all the core files stitch together, however, I got to this solution by noticing the daylight_setting (line 127) value for userdata within Session.php was being set with this:

'daylight_savings'  => ($this->EE->config->item('default_site_dst') && $this->EE->config->item('default_site_dst') != '') ? $this->EE->config->item('default_site_dst') : $this->EE->config->item('daylight_savings'),

To me, this is setting the value based on two config settings and at no point reading data from the database. Therefore, any DST value I was adding to the Localization Settings within the Control Panel was not having an effect.

In addition,  I noticed that the get_localization_default function (line 1480) within the member_model.php was setting the default_site_dst to empty as localization_is_site_default, as far as I can tell, is always set to n.

I’m not a programmer so this could be a red herring, however, I hope this helps.

Hi Thoughtful Web,

Sorry for the delay in response to you! Thank you for all of the leg work and sleuthing you’ve done.

ExpressionEngine changed a lot of date/time handling between EE 1 and EE 2.

This all starts at the server - the server’s time, DST and timezone should all be correct. Then ExpressionEngine needs to be set to match the server’s timezone and DST setting.

These 2 items:

$config['default_site_dst']

$config['default_site_timezone']

Can be set to tell EE to set everything to a “base”. Let’s say your server is in one timezone, but the client is using EE from another timezone and you want EE to behave as though the server is in the user’s timezone.

Clear as mud, no? 😉

If you verify all those points and run your tests again, can you share with me the results?

Cheers,