Incorrect time shift for recurring events over Daylight Savings Time -> Standard Time change

I'd say having people turn up an hour early / late is a major bug.

I agree that this is a major bug.

Can/will it be fixed for 2.0?

Is there a workaround for this bug?

This will only happen if "Location settings" are left with the default value for "Default timezone" - server's local time.
If you "Update timezones" and then set default timezone to something like "Europe/Dublin" - the events will work as expected.

With the current implementation of date & time in Moodle (as timestamps) there is little that can be done if you don't provide Moodle with correct timezone information. It will also be difficult to fix the times retrospectively - you need to set the timezone first, and then create the events.

Bruce, Barbara, Hurstel,
Can you confirm that the above is correct? Or is there some other problem with the calendar, I'm not aware of?

Raising this to critical, moving to stable backlog.

Needs review asap, surely testing it under different combinations of moodle/user timezones (including "server default" and some real like "Australia/Perth" one). And also, depending of PHP's own timezone settings (to see if that is affecting Moodle's own calculations).

Once found all the offending combinations... we'll need to determine if they are fixable or no, as far as some of them can be irresolvable if not real timezones are selected. Also note that user always has precedence over global one so, for testing is enough with trying user timezones.

Ciao

Just a thought, is there any way to check that the PHP setting is set?

Testing steps
-------------

Requirements:

• you need access to your server php.ini settings
• you need access to your server operating system date/time settings. Your server OS must be set to a location supporting DST. Set it to London.

0. edit your web server php.ini with date.timezone = 'Europe/London' then restart it
1. Connect as admin and edit your profil. Set timezone to 'server default'
2. Go to a course, select new event (in 'upcoming events' block)
3. Create a event starting the 1st october 2011 at 13 (1PM) and ending the 1st October 2011 at 14 (2PM), repeating 6 times
4. Edit the event of the 1st october and the event from the 5th october, they should both start to 13 and end at 14. (1st October is a DST time in London, 5th November isn't). Also check that they are well in displayed in the calendar (it should be written from 01:00 pm >> 02:00 pm)

5. Edit your profil, set timezone to 'UTC'. Repeat 2 - 4 steps.

6. Repeat 1 - 5 steps, but with the first event starting the 1st March 2011 at 13 and ending at 14, repeating 6 times.

7. Edit your web server php.ini with date.timezone = 'Europe/Paris' then restart it. Repeat 1 - 6

8. Change your OS time to a DST time if it was not a DST time (or opposite). Repeat 1 - 6

Number of iteration: 16. Once you have done few iterations, it's quite fast to run the other ones. Keep track of your testing Good luck.

I need someone to review the code logic of this commit:
https://github.com/mouneyrac/moodle/commit/e1bcacf37dee127157e1fe2e11e95b5c247eecd1

What it does when 'server default' is selected in user profil:

• if the event start time is a DST, then Moodle save the event in the database with a GMT-1. The event should always have the same GMT hour whether the first event is a DST or not. It's because we use make_timestamp()/mktime() that automatically apply DST offset when timezone is not set to UTC. This commit fix it.
• when the event is DST, it is displayed with +1 hour. It's because we use usergetdate()/getdate() that automatically apply DST offset when timezone is not set to UTC. This commit fix it.

There is still many 'displaying time' pages to fix but I just want to confirm first if it is the correct logic.

PS: I deleted some of my previous (obsolete) comments to keep this issue as small as possible for the QA tester.

This patch is definitely dangerous. Screwing around with specific timestamps by adding or subtracting 3600 in certain places is not reliable. (Are you sure that DST always adjusts things by one hour, always, in every country, no matter how crazy the government is?)

Also, you seem to be changing the code that creates and displays the events, whereas the original bug report relates to creating recurring events. I would expect that the bug fix would affect the place where recurring events are added to the database. Providing the date is added to the database correctly, then in future it should display correctly.

The safe way to manipulate dates, for example to go from 10:00am Monday one week to 10:00am Monday the next week, it so use a good date library. For example after much grief with this at the OU, we have now standardized on http://www.php.net/manual/en/function.strtotime.php (or gmstrtotime, sorry, I can't remember which one is right) with a first argument like "+1 week".

Hmm. That probably still relies on the server knowing the right time zone.

Actually, the problem as stated so far is not even well designed. What happens on a site like Moodle.org when you have different users in different time-zone regimes. What happens in Helen, sitting in Brussels where they have one sort of DST, wants to create a recurring event from 10:00am on Monday in Perth, Australia?

Perhaps the only reliable option is, that when creating a calendar event, there is an option on the form to select the time-zone of the event. (That should obviously by hidden by show advanced, and default to the current user's timezone. Then, at least, it is clear exactly what data we are trying to write to the DB.

I also wonder whether we should deprecate the "Server time" timezone, and try to push everyone to select a real timezone. That would also make everything clearer.

Thanks Tim for your good comments.

I spoke about this issue in our daily meeting. Here are the conclusion (matching yours):

1- we should use the real DST offset (not +3600/-3600). We have the information in Moodle, maybe it needs to be updated. We have updated DST offsets on Moodle.org
2- We could mark 'server default' as deprecated and forcing user to change to a UTC (Note: we need to check in Moodle if there is no other bug like the event one, where created DB timestamps are different in UTC-X or 'server default' for the same timezone.)
3- we need to identify the right way to create recurrent events. Do people want an event at the same moment (a internet meeting) or recurrent at the same hour (course time at 3PM, DST or not)? Do we want to add a settings like that in the create event page?

More feedback from the community about 2-/3- and this issue is welcome

People can also want to follow the forum topic here: http://moodle.org/mod/forum/discuss.php?d=167302

sorry wrong issue

We talked about it with Martin, we decided to remove the 'Server Default' from Moodle. I created MDL-26391. It should resolve the DST event problem.

hehe, just a side comment... won't be the cause for this shift... the fact that the events themselves must have one "timezone" attribute.

I mean, if I create the event "Moodle HQ meeting" every monday at 09:00 (London), then I should see that event happening at 09:00 all the year (no matter of DST), but somebody @ Perth should see it at 15:00 or at 17:00, depending of Perth's difference with London with DST on/off. i.e. the key here is that events must know under which tz+dst were created.

In fact all current calendars make you to define your "input" tz. Else, the thing isn't computable at all.

So I'd be really careful before playing too much and taking out things... just a quick thought based in my previous experience with the tz implementation of Moodle. Perhaps the problem is in the definition of "event" and not it the tz/dst/server default thing.

Ciao

(wrong bug report, sorry, please delete the attached wiki_uid_0.log. Thanks)

We ran into a side effect of this: the default start time for an event is at midnight, so if we create a weekly event from September to December (says, Tuesday) with the default starting time, when it get passed the DST somewhere near the beginning of November, the days get shifted to Mondays.

For a short-term workaround, perhaps I'll have to add a site-wide option to Calendar block to set the default starting time, probably to something at least an hour away from midnight.

This is still an issue in 2.4. This is affecting us too in the America/Los Angeles time zone. All of our due dates that extend past November 4 are coming up an hour earlier requiring us to do massive corrections on the course shells. This is very tedious and time consuming. We would like our due dates to not be flexible, even when the time is!

Dear All,

Any updates concerning a fix for this problem, we are using 2.4.5

Regards,
Anis

We are experiencing this issue during backup and restore. Its affecting all of our due dates for assignments on the restore and moving them forward or back by an hour accordingly.