Thread

Hi!

I’ve experienced a huge problem on our site:
a user enters events (entries - the entry date is the time of the event and the event lies in the future). The user (lets call him ‘john’) has the same time-zone set than the time zone of the super admin and the default time zone of the system. Daylight saving settings are also equal.
Now in europe (where the site runns) time changed to normal time (no dst) lately. What I did was to change the system dst setting to “no” (administration > localisation), I also changed the super-admins dst settings to “no”, and I changed the dst setting of the user ‘john’ that enters the events to “no”.
The Problem is, that the time of all the events ‘john’ entered shifted one hour into the past!! Meening: if the event was set to 18:00 the site now displays 17:00 - which is a real problem.

I’ve tried to change back the super-admins dst settings to “yes” which makes the events shift back to the correct time.
Btw: Changing johns dst settings did not change anything. Is this because the super-admins settings are marked as the default - and so the local settings of john are ignored?

Now when creating a new entry the entry-date is one hour in the future which is also problematic…

What did I do wrong, as far as I understand it, the entry-date should not be changed (even for future entries) as long as the servers dst and the users dst settings correspond??

Btw. I’m using EE 2.3.1

Hi timoteus,

I’m sorry you’ve bumped into this as a problem. 2 things here, the DST setting for the server and each user should be set correctly and maintained throughout the year as DST goes into and out of effect. When you change either the server’s setting (the entire system will be affected) or a user’s setting (that user’s entries will be affected), ExpressionEngine will adjust the timestamp accordingly.

So to clarify, if the server is in a timezone that has DST in effect, the setting should be on for the server and if a user is in a timezone where DST is in effect the setting for the user should be on. ExpressionEngine store’s times in GMT and adjusts on the fly (for display and output) based on those settings.

Cheers,

Hi Dan!

Ok so far - but that does not answer my question.

On my system: DST was set correctly for the user (lets call him ‘john’ again) and for the system - they are in the same time zome (UP1).

Then, when in our time zone DST went out of effect (last week) I changed the system setting (DST to off), and the user (‘john’) changed his setting too DST to off.

But nevertheless all the future entries of john where shifted by one hour. Does anybody else experience these kind of behaviour?

I’ve tried this on a fresh EE installation, and the time shifts!!

Done the following:

Fresh EE 2.3.1 Install on Linux Server which runs in UTC+1 zone. One Channel two users. Set Timezone to UTC+1 and DST of system and user to “No”.  User creates Entry in Aug. 20th 2012 12:00.
In Aug. we will have DST in the UTC+1 time zone.
So simulate Aug.:
set linux server time to Aug. 1st, set users DST setting to “yes” and set system DST setting to “yes”.

The problem: the event-date now shows me 20th Aug. 2012 13:00!!

This is reproducible! - Could this be a bug?

And by the way - to make the DST setting automatic would be a good feature request - setting the time zone should be sufficient for the system to tell if the user is having DST or not!

What do you say?

Hi timoteus,

The scenario you described is expected behavior. If you are simulating a point in time where DST is in effect, August in your example, and you *don’t* have that turned on, then make an entry, then turn DST on, it will adjust the time. When performing an installation, DST and timezone should be accurate at the time of installation. Changing those settings after the fact will have an effect on your timestamps.

Again, to clarify, timezone and DST setting should be accurate for the server and the users, regardless of where the user or the server reside. Automatic changeover would make an excellent Feature Request! Likely would involve a cron job to be effective though.

Cheers!

Hi Dan!

Thank you Dan, but now I’m very confused.

First: in my “simulation” I also set the Server time correctly, which means I set all the DST Settings accurately for November (including the Server). Then I simulated August (All settings accurate including the Server).

So if I understand you right, I should set the DST Settings for the Server and the user correctly at time of EE installation. OK so far, that’s what I did - so everything is accurate. You said: “Changing those settings after the fact will have an effect on your timestamps”.
Well, in the User Guide it says that I have to change these settings for the installation when DST changes - as you said, to be accurate. (http://ellislab.com/expressionengine/user-guide/cp/admin/localization_settings.html).
Of course, the user also has to change his settings - that’s what he did - so the settings are both accurate. Also the server time was accurate - so I don’t see my error.
But nevertheless the time of the event changed by one hour.

I can’t believe that this is expected behaviour!!

I can’t further believe that you meant that my user has to change his DST settings (to “on”) if he wants to enter an event for August in November?!

And by the way: in my EE installation there is no “Honor the Daylight Saving Time setting associated with each channel entry” item in the CP like it is said in the user guide. Maybe that’s the problem.

In the Database the entries have a column called “dst_enabled”. For all my entries this column says “n”. Maybe that has something to do with it.

So my Question: What did I do wrong - and what should I do in the future to avoid a time-shift of the entries?

Someone else is expecting the same behaviour…

http://ellislab.com/forums/viewthread/203759/

Hi timoteus,

You didn’t do anything at all wrong. As you can imagine, we have been having some discussion about this because of the recent DST changeover. From our discussions and testings, it appears that ExpressionEngine could be handling this incorrectly. Not your fault at all, and not expected behavior. I apologize that my attempts to explain led to further confusion, that is not at all helpful.

The setting you mentioned is no longer available and the column in the database where that was stored has been kept for legacy purposes, but is no longer read, so the value stored there has no effect either way.

Hi Dan,

no problem, thanks for your reply, I’m just glad that I didn’t do anything wrong.

It would be helpful though to get that bug squashed before the next DST shift.
By the way, I haven’t posted a bug report yet and can’t find a suitable report, so I’m going to post one.

Cheers

Hi timoteus,

Yes, please post the report, but know that we are very aware of the issue and are discussing how to approach a fix. With that being said, is there anything else I can do to help, or do you mind if we close this one down?

Thanks for your patience!

Thanks Dan, you can close the thread!

Hi timoteus,

Thanks for bearing with us on this. The Devs are actively working on a solution, but the fix will require some big changes in order to implement.

If you need us again, please feel free to start a new thread.

Thanks!

resolved.