I recently setup EE in production and had some templates that were time-sensitive. In these templates I was using JavaScript to countdown to open a feature in case a member accessed the page in advance. The countdown was basically a difference between {current_time} and an entry's Date field.

This was my introduction or rather re-introduction to EE's DST. In the Admin -> Localization Settings they literally mean your server's time zone and DST settings, not the settings you want for EE.

Problem I faced:

The timing was off by an hour. I would see the correct time as desired when punching in the Date field, but the epoch time stored in the database was actually an hour behind. Yet {current_time} in a template was perfectly fine.

Attempted fix:

My server's time is in UTC and at present DST is not in observance (I just assumed this is somehow automatic), despite changing those settings the Date field would be stored as "UM5" (GMT -5 or EST, the time zone for New York which is what I want) and still be an hour behind.

Temporary fix:

Reading up on previous discussions I turned off localization for users and set a Super Admin's setting as the master site default. There is no longer an "Honor the Daylight Saving Time setting associated with each weblog entry?" setting, nor does it seem that anything gets stored associated to a channel or entry (please correct me if I'm wrong here), so this feature seems to be gone altogether. This did the trick for me in the sense I could now put a desired time as seen in YYYY-MM-DD hh:mm [AP]M format and get stored with the desired epoch value....

Problems that remains:

  • All previous entries' time are now behind by an hour. That is not a problem for me at the moment, but I probably wouldn't want that to happen. If a content editor or manager punches in a datetime, say, November 18th at 9 AM, that time should never later on become something different, whether 8 AM or 10 AM.

  • What if I want to respect users' localization settings? For now they're off and I couldn't yet determine if they're relevant or not.

I found the following post by post by Ryan Masuga (via this blog entry) which seems very useful for dev/staging/production configs, automating enabling/disabling DST, using a config variable instead of a member's settings (difference between server_timezone and default_site_timezone), but it doesn't seem like it will affect retrofitting these settings onto all previous dates when that is not desired.

I haven't been exposed to how else this might be a problem so I guess for now how do you keep fields that were saved whilst DST was observed the same even while DST is no longer observed?


Here's a code sample similar to what I use for my configuration (credit to Steven & Adrian for the Gist)

(note it's $config, not $conf, don't know if the latter legacy thing has any effect)

(For timezone codes like UM5 below see: Code Igniter: Date Helper: Timezone Reference):

// @link http://expressionengine.com/forums/viewthread/195956/#922322
$isDst = date('I') ? 'y' : 'n'; // or see discussion below for timezone-specific dst, not sure if it should be done given EE will make up the difference
/* @link https://gist.github.com/3969207      
$dateTime = new DateTime();
$dateTime->setTimezone(new DateTimeZone('America/New_York'));
$isDst = (bool)$dateTime->format('I') ? "y" : "n";
$config['time_format']           = 'us';
$config['server_timezone']       = 'UTC';
$config['server_offset']         = ''; 
$config['daylight_savings']      = $isDst;
$config['default_site_timezone'] = 'UM5'; // GMT - 5
$config['default_site_dst']      = $isDst;
//$config['honor_entry_dst']       = 'n'; // No longer exists

Any new date fields will be entered properly, however, existing fields will be off by one hour. The problem remains. Entries punched in while DST was on will be off by an hour while DST is off, similarly entries punched in while DST was off will be off by an hour while DST is on (albeit the other direction).

How do we solve the alternating 1-hour off problem? The discussion on the github gist does not solve this except via manual database queries...


ExpressionEngine 2.6 will be removing these DST issues altogether, which makes me wonder about upgrade issues... and we'll have to do with these config variables already in use in a bootstrap... here's to hoping their docs on the matter will be thorough/comprehensive...

  • 1
    Did any of the answers help you? If yes, please mark the answer correct by clicking on the checkmark to the left of the answer. – Anna_MediaGirl Dec 22 '12 at 6:18
  • There are nice comments that added little more than I had linked to originally, but none actually answer the question/provide a solution. – notacouch Dec 23 '12 at 17:19
  • 1
    Did you answer it on your own? If yes, you can answer the question and select your own answer as correct. If no answer yes, let me know and I help promote it on Twitter. – Anna_MediaGirl Dec 23 '12 at 22:30
  • I did not answer it on my own, thanks Anna. – notacouch Dec 24 '12 at 16:41

As Steven said, there is a handy workaround to automatically set the current timezone. Elaborating:

Add the following to your config.php file (replacing the America/New_York timezone with one from this list of supported PHP timezones):

var $dateTime = new DateTime();
$dateTime->setTimezone(new DateTimeZone('America/New_York'));
$isDst = (bool)$dateTime->format('I') ? "y" : "n";
$conf['daylight_savings'] = $isDst;

Note this will only work on PHP 5.3+ (which you are most likely already using, unless your host is extremely outdated).

Source: https://gist.github.com/3969207

  • 1
    Thanks for posting the actual code here, better to keep the stuff on the same page. – Isaac Raway Nov 20 '12 at 1:23
  • "there is a handy workaround to automatically set the current timezone" when I saw the code: $dateTime->setTimezone(new DateTimeZone('America/New_York')); that looks to me like it's only setting the timezone for that specific $dateTime object, no? But I get what you're saying, instead of just date('I')... this would make sure the timezone is as desired for DST itself which date does not ensure. Would've glossed over that. 2 questions: 1) wouldn't var $dateTime only be valid within a class? 2) conf[..] or config[...]? However, this doesn't fix past entries becoming 1 hour off. – notacouch Nov 21 '12 at 16:31
  • You're thinking about it too much, just copy the code :) The last line takes the DST setting out of the $dateTime object and puts it into EE's $conf array. – Adrian Macneil Nov 21 '12 at 23:21
  • 2
    I did use the above code/gist earlier today. Got a white screen presumably because of var $dateTime (just $dateTime is fine). The rest of the config settings are in $config, not $conf. Setting the timezone is still handled by $config['default_site_timezone'] not via anything in the gist. See errors in: PHP 5.3.18, PHP 5.4.8 – notacouch Nov 22 '12 at 1:45

Here's a solid work around for fixing the DST issues in EE. https://gist.github.com/3969207

  • 1
    Best to copy the actual code here and link to the source (especially since it's only a few lines), as links can become invalid over time. – Adrian Macneil Nov 20 '12 at 1:18

I'd like to cross reference the answer I posted here Forcing DST settings for users.

Even once you nail down the users's localization you might still end up with times that are an hour +/- if you are creating an entry with a date field that end up in a different DST state.

The issue is EE has no record of what the DST state was when the entry was saved. This is fine if all you are concerned with is dates that exist in the past but you will have to re-save entries during the new DST state for dates that occur in the future because they'll be +/- 3600 seconds off.

  • Thanks for sharing, I've noted a number of those things albeit not in code. Good to have it in one place. We do live broadcasts on Sundays. I really need to set up my dev and live site to use configs with hidden variables. old dev entries were 2 hours off, old live entries 1 off, new entries were just fine. Another problem is that I clone entries so I didn't take a second look at datetimes. This is really strange behavior, we should never have to take a second look, edit retroactively, etc. Neither the editor nor EE will recall what time was originally intended, it's a shame. – notacouch Mar 11 '13 at 15:18
  • imo until EllisLab gets this right perhaps someone ought to create a custom fieldtype to workaround EE's dst nuances (and like when saving an entry... the lack thereof). – notacouch Mar 13 '13 at 19:39

This is resolved in EE 2.6+ by upping the minimum PHP version so they could make use of native stuff for date/time as well as having reintroduced the honor_entry_dst setting.

For EE 2.6+ See: In EE 2.6 how do we set different localization/timezone site-wide than the server's timezone?

Prior to EE 2.6 there is one [commercial] fieldtype add-on I know of that seems to either resolve or ignore EE's timing issues altogether and that is Low Events.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.