Fix for bug 1365:

This one was most insidious. Usually we get bugs that have to do with the
user/server timezone interaction, but by now I 've learned to be extra
careful about that. This one, however, only had to do with the server's
timezone and was 100% certain to happen if you are GMT minus something.
Considering that I 'm GMT+2, it went unnoticed. Sorry!

diff --git a/calendar/lib.php b/calendar/lib.php
index ae9cf7537750d24a0b92bc34c88f47728c9c58f4..662eeffedc8bbdfbe4ec319996afba5f80292ced 100644 (file)
--- a/calendar/lib.php
+++ b/calendar/lib.php
@@ -478,7 +478,7 @@ function calendar_top_controls($type, $data) {
     if(!isset($data['d'])) {
         $data['d'] = 1;
     }
-    $time = calendar_gmmktime_check($data['m'], $data['d'], $data['y']);
+    $time = calendar_mktime_check($data['m'], $data['d'], $data['y']);
     $date = getdate($time);
     $data['m'] = $date['mon'];
     $data['y'] = $date['year'];
@@ -524,7 +524,6 @@ function calendar_top_controls($type, $data) {
         break;
         case 'display':
             $content .= '<div style="text-align: center;"><a href="'.calendar_get_link_href(CALENDAR_URL.'view.php?view=month&amp;', 1, $data['m'], $data['y']).'">'.strftime(get_string('strftimemonthyear'), $time)."</a></div>\n";
-
         break;
         case 'month':
             list($prevmonth, $prevyear) = calendar_sub_month($data['m'], $data['y']);