Jump to content


DST not taken into account on display

Member 1

Timezone GMT
DST in use

Member 2

Timezone GMT
DST not in use

If we add a calendar event at 6pm GMT, member 1 should see this event as 7pm and Member 2 should see it at 6pm.

What is happening is no dst offset is applied to the display time so both members see 6pm.

$this->memberData['time_offset'] which is applied to the display times is 0 for both of these users.

Outside of Calendar, when we use the parse date tag, the offset is applied in classLocalization::getDate() which accounts for DST. In Calendar we only use the time_offset in memberData.

Status: Fixed
Version: 3.3.1
Fixed In: 4.0.0 Beta 1


Where is this issue? Just viewing events, all throughout calendar, etc.?
Wherever an event time is shown which as I understand it is only on the event view. It would also cause events to show on the wrong day around midnight though I guess so all throughout Calendar.


None of these times are corrected to account for member DST settings, only the time zone offset.
In researching this, anywhere we manually apply the offset we should be able to just grab $this->registry->class_localization->getTimeOffset() instead. This takes into account member vs guest time zone offset, DST and the ACP time adjustment. I've added a param to this method to allow us to ignore the ACP adjustment (which I think we'd want to do for Calendar) into 3.3.2 - going to look closer at this after 3.3.2 is out, but we'll be prepared in any case.
The problem with this issue goes deeper. When you submit an event, whether you are in DST or not, that hour is never taken off the stored time (so if you say GMT-5, it takes off 5 hours whether you are in DST currently or not). If I submit an event for 7PM GMT-5, and I'm in GMT-5, it shows as 7PM. If we start accounting for DST, it would make that wrong, and/or we would need to account for it during submission as well (which would make currently stored events "wrong"). Further, the subtraction is ALWAYS going to go based on your CURRENT DST time. So say I submit an event as 7PM GMT-5 for May and I take into account DST and it's all correct. Come November, if I look at the event, it's going to be an hour off, because I'm no longer in DST (so it isn't taking that off the time any more). The code isn't going to remember that you were in DST when the event was submitted.

This is going to require much more consideration than I originally anticipated, so I'm going to put it on hold for now. Technically, GMT-5 is GMT-5, whether you are in DST or not, so this is more an enhancement than a bug.
Unless I'm misunderstanding we don't need to account for DST on storage. The input specifically requests a GMT-x time with no accounting for DST. So long as all dates are stored relative to GMT then I believe it is only the display that needs to be adjusted for DST. In other words GMT-5 is always the same regardless of whether DST is in use or not.
    • Marcher Technologies likes this
Right, the real problem is that it's not really GMT-5...it's UTC-5. However, when you are in DST (here on the east coast), we're actually UTC-4. GMT adjusts too, so we're GMT-4 for a few weeks and then GMT-5 again once you guys start DST.

If I save an event for 7PM in GMT-5 right now, it shows as 7PM. If I take into account DST (which is enabled for me at the moment), that's going to change the time by an hour, even though I submitted it as 7PM in GMT-5. If we don't account for that on storage too, it will mean when I submit a time, it's not going to be accurate while DST is in effect.
Did this ever get fixed?

It was I who started the ticket on this whole process and it is still posing quite a problem for us.
As you can see the bug report is still marked as confirmed.
This also affects RSS (which show the times of course)


Submit an event as 10:00PM GMT-5. Shows properly in Calendar (at least for you). We don't account for DST in displaying the events.

When you export the event, it is exported as GMT time (e.g. 03:00 GMT ... if you subtracted 5 from it, it would be 10:00 PM). The "problem" is that since DST is enabled, external sources (e.g. a browser) knows this and honors the hour offset for DST, making it display as 11:00 instead of 10:00.
Marcher Technologies
Jul 19 2012 10:31 PM
ick, ok, can i get an idea of which way this one will blow?
I've been manually breaking what you store down into it's parts and running IPSTime::date_gmmktime on said parts, then passing it into parse date with checks for all day as to whether to show the time, and it appears to be correctly handling the DST in all cases... but I do loath inconsistency... is the consensus going to be to enforce or ignore it?
Yea I would really like this to be fixed too. I run a forum for an online game and have members from all over the world. So when an event is posted it doesn't display correctly for people. :/
Updating Fixed In to: 0

The changes required to resolve this are not suitable for a maintenance release. The issue will be fixed in the next major version.
Updating Status to: Will Fix - IP.Suite 4.0

Updating Fixed In to: 4.0.0 Beta 1
Updating Status to: Fixed