some double backslashes present yet. This method doesn't addslashes()
automatically like the old one (so kses_stripslashes() is not needed).
All we have to to is to stripslashes() before calling kses and addslashes()
after it. Only in clean_param(), because params arrive always slashed
to Moodle. This seems to be the correct approach documented in:
http://sourceforge.net/project/shownotes.php?group_id=81853&release_id=302996
1. When user was using "Server's local time", and the server was set up to
use DST, generated timestamps must have been wrong in DST periods (I
haven't backtracked to test this, but the code reads this way).
2. On Eloy's Mac (let's not generalize without data), passing is_dst = 0 to
gmmktime caused it to return WRONG results!
The PHP docs clearly state that in_dst does NOT affect the return value,
which is true for me but in Eloy's case it was a lie. Obviously PHP bug here.
Also, moved the if($applydst) check into the else branch because it would do
nothing at all if (abs($timezone) > 13) in any case.
I hope Eloy keeps finding more bugs because he promised me a beer for this fix ;-)
Since we 're at it, fixed another bug: automatic recalculation of DST table
without having to logout if the user changes his timezone now works correctly.
2. usertime: I think that the way Moodle is written, if this compensates for DST lots
of things are going to break. I found a few myself and decided to revert the behavior
until such time as a proper code review can be made.
user's effective timezone correctly using get_user_timezone(). It also remembers
which timezone was in effect when it cached its calculations, so if the user's
effective timezone changes for any reason the table is automatically re-computed.
******
NOTICE
******
From this point onward, DST support should be working again, and there are no more
visible hurdles in the way. This means it should STAY working correctly until 1.5.
1. calculate_user_dst_table() works correctly and offers many features:
Can create or extend on-the-fly a table of pre-computed timestamps on which
DST changes happen, keeps track of these changes and the current computed year
range in $USER->dstoffsets and $USER->dstrange. Initially the computation is
done in a current year +/- 3 years range, to keep the amount of serialized
data small and to make traversals of $USER->dstoffsets faster.
2. dst_offset_on() works correctly, and can dynamically instruct the above
function to extend the pre-calculated region on demand (i.e., when it's called
for a timestamp which falls outside said region).
3. Some other improvements.
I have made a few preliminary tests on my dev machine and It Works(tm!) :D
