15

Context:

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?

EDIT::

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'));
$dateTime->setTimestamp(time());
$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...

Edit:

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...

Improve this question
4
  • 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, 2012 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, 2012 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, 2012 at 22:30
  • I did not answer it on my own, thanks Anna.
    – notacouch
    Dec 24, 2012 at 16:41

4 Answers 4

Reset to default
13

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'));
$dateTime->setTimestamp(time());
$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

Improve this answer
4
  • 1
    Thanks for posting the actual code here, better to keep the stuff on the same page.
    – Isaac Raway
    Nov 20, 2012 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, 2012 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, 2012 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, 2012 at 1:45
2

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

Improve this answer
1
  • 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, 2012 at 1:18
1

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.

Improve this answer
2
  • 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, 2013 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, 2013 at 19:39
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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