Thread

Is there any news on this issue? I’m experiencing something similar.

I have a channel for our events, that has a custom field for the actual date of the event itself - using eevent helper, it sets the expiry for midnight the day of the event so that it clears away off our site.

I noticed that whenever I go back to edit an entry - even with eevent helper turned off - it pushes the event time (but not the entry time) forward one hour. With eevent helper turned on, it will push it forward by two hours. When eevent helper is turned off, it only starts pushing the entries ahead by one hour after March DST, even though everything on my site has it turned off (both member profile & localization setting).

But it’s not that it just pushes it ahead one hour on the site - it cumulatively adds an hour every time someone saves an edit - this is viewable from the entry preview after I hit ‘save’.

What version and build of EE are you using? There were some changes concerning DST recently.

2.1.3 - I’d downloaded and installed it on Dec 26th.

Stephen T,

I just replied to you via email. Apologies for delay.

Sometimes the time jumps forward one hour for both the entry date and expiration date, and other custom date fields on the same entry.

Yikes, I’m having the exact same thing happenning. Superduper weird.

It doesn’t happen with all the entries though, just a few of them in my events channel.

@John, Maybe fill me in on any details you emailed Stephen previously.

Please see this bug report.

I’m having the same issues and it’s creating major issues as the website is mostly a calendar of events so participants are getting quite angry about the incorrect information.

I’ve tried removing the suggested code in the bug report and it doesn’t resolve the issue.

If I create a new entry or change an existing entry, the dates display an hour ahead of the time they display in the control panel.

I haven’t imported any data, I just upgraded to the new EE2 and the calendar has way too many events to manually change at this point.

How can I resolve this issue?

It’s been fixed for the next release. Perhaps you’d like to try with the 2.1.4 Beta?

I would! How would I obtain a copy? Thank you!

Go to your regular download, download EE 2.1.3: on the licensing page you’ll find a radio button that let’s you download the Beta (or EE 1.7, for that matter) instead. Makes sense?

Yes, thank you. I downloaded and installed EE 2.1.3 and the time issue still exists. Every entry displays correct in the admin, but shows on the website as being an hour earlier. Daylight savings is off and the time zone is eastern.

Suggestions? Thanks.

I’ve got the same issue - a custom date field with values entered after daylight savings time shifts an hour ahead whenever I ‘submit’ from the entry edit page.

I just upgraded to 2.1.4 beta to test it, and the behavior is the same - the bug is still there.

Another interesting detail… if I use php code in the template to display the value in the custom date field, the displayed time shifts ahead another hour. That is, for example, the time displayed when using the regular template tag {custom_date_field format=...} is 12:00pm, while the time displayed using <?php echo date(‘format’, {custom_date_field}) ?> is 1:00pm.

Hi, kindermaur. I logged another defect for EE 2.1.4 beta this morning.. https://support.ellislab.com/bugs/detail/15346/ Does this sound like what’s happening with you?

Yes, that sounds like it. I seem to remember a very similar bug that got fixed last summer, only with entry/expiration dates. Any estimates on the time to fix?

I’m wondering what will happen to these times after the DST switch. Will the manually entered offset-times we’re using as a workaround have to be re-entered without the compensating offsets after DST begins?

Would it be helpful if I set up a test install where I can change the server’s date & timezone?

kindermaur,

Any estimates on the time to fix?

We don’t provide any. The devs work through bugs in order of severity. Keep an eye on the Bug Report for a status update.

I’m wondering what will happen to these times after the DST switch. Will the manually entered offset-times we’re using as a workaround have to be re-entered without the compensating offsets after DST begins?

That may well be the case depending on the fix that goes in place

Would it be helpful if I set up a test install where I can change the server’s date & timezone?

I would say not for now but certainly leave a comment on the Bug Report that you are willing to do so. It will also subscribe you to the report so you will receive email when somebody replies or it is updated.