Calendar 0.7.13, recurring events and Daylight Time
Posted: Fri Mar 21, 2008 6:16 am
I am running Calendar 0.7.13 and CMSMS 1.2.3 with PHP 5.88 and MySQL 5.0.45 and Apache 2.2.4.
My host server is located in the Eastern United States. The calendar is on a website for a school in Saskatchewan, Canada. The server is on Eastern Daylight Time and Saskatchewan is in the Central timezone but never goes on Daylight Time.
When I post a recurring event that takes place at 3pm, the script changes the time to 4pm when Daylight Time is in effect (eg. after March 8th). This is not desirable for at least two reasons: (1) Saskatchewan doesn't change time, and (2) even if it did, a regularly scheduled meeting doesn't change its start time when Daylight Time is in effect.
I have tried fixing the problem in the following ways:
(1) set the TZ environmental variable in .htaccess using "setEnv TZ Canada/Saskatchewan" -- this had no effect whatsoever.
(2) added the line "putenv('TZ=Canada/Saskatchewan');" to config.php -- this had a very strange effect. The initial occurrence of the event was scheduled for 3pm as desired. The next occurrences of the recurring event were set by the Calendar script to start at 4pm until Daylight Time kicked in at which point the script set the events to occur at 5pm!
(3) deleted the putenv call and added the line "date_default_timezone_set ('Canada/Saskatchewan');" to config.php -- this had the same effect as in (2).
In both (2) and (3), current time did change from EDT to CST but the Calendar entries were wrong.
I had a second look at the module scripts and I saw where the problem is: events occurring weekly have 7*24*3600 seconds added to their start date in unix time format to get the new start date which of course, doesn't allow for the lost 3600 seconds that occurs when Daylight Time starts nor the 3600 seconds gained when Daylight Time ends.
Hacking the script to check for Daylight Time boundaries is not really a solution as different parts of the world go on Daylight Time (or something similar) at different times of the year. Not to mention hacking the script causes upgrading problems in the future.
Is the only workaround to never repeat an event across the boundaries of Daylight Time? Does anyone have a better solution? Is there a fix in the works? (Recurring event dates should probably be calculated differently to avoid this problem.)
Leslie
My host server is located in the Eastern United States. The calendar is on a website for a school in Saskatchewan, Canada. The server is on Eastern Daylight Time and Saskatchewan is in the Central timezone but never goes on Daylight Time.
When I post a recurring event that takes place at 3pm, the script changes the time to 4pm when Daylight Time is in effect (eg. after March 8th). This is not desirable for at least two reasons: (1) Saskatchewan doesn't change time, and (2) even if it did, a regularly scheduled meeting doesn't change its start time when Daylight Time is in effect.
I have tried fixing the problem in the following ways:
(1) set the TZ environmental variable in .htaccess using "setEnv TZ Canada/Saskatchewan" -- this had no effect whatsoever.
(2) added the line "putenv('TZ=Canada/Saskatchewan');" to config.php -- this had a very strange effect. The initial occurrence of the event was scheduled for 3pm as desired. The next occurrences of the recurring event were set by the Calendar script to start at 4pm until Daylight Time kicked in at which point the script set the events to occur at 5pm!
(3) deleted the putenv call and added the line "date_default_timezone_set ('Canada/Saskatchewan');" to config.php -- this had the same effect as in (2).
In both (2) and (3), current time did change from EDT to CST but the Calendar entries were wrong.
I had a second look at the module scripts and I saw where the problem is: events occurring weekly have 7*24*3600 seconds added to their start date in unix time format to get the new start date which of course, doesn't allow for the lost 3600 seconds that occurs when Daylight Time starts nor the 3600 seconds gained when Daylight Time ends.
Hacking the script to check for Daylight Time boundaries is not really a solution as different parts of the world go on Daylight Time (or something similar) at different times of the year. Not to mention hacking the script causes upgrading problems in the future.
Is the only workaround to never repeat an event across the boundaries of Daylight Time? Does anyone have a better solution? Is there a fix in the works? (Recurring event dates should probably be calculated differently to avoid this problem.)
Leslie