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.