I posted a detailed question about some problems I'm having with the Daylight Savings Time switchover in the General Problems forum (see this post).
Short version: I've noticed that on our server, the availability of assignments that are scheduled after the U.S. switch to Daylight Savings Time becomes off-kilter by an hour. A quiz that says it should be available at 12:00 on March 12th, for example, doesn't let students open it until 1:00 on that day. Our timezone files should be pretty up-to-date (rpm -q tzdata reports tzdata-2006m-3.el4), and Moodle's time zone is set to America/Los_Angeles. This happens no matter what the time zone in the user's profile is set to. Quizzes before March 11th, the new switchover date, are fine.
That was the original problem. In researching it, I noticed that Moodle's time zone file (moodle/lib/timezones.txt) doen't have an entry for the new effective date for DST in the U.S. (which is now the second Sunday in March instead of the first Sunday in April). I couldn't find a more recent version of that file at http://download.moodle.org/timezones/, and I was thinking about adding a manual entry, at least for our time zone. The line for 2006 (with field headings) is:
id,name,year,tzrule,gmtoff,dstoff,dst_month,dst_startday,dst_weekday,dst_skipweeks,dst_time,std_month,std_startday,std_weekday,std_skipweeks,std_time
1198,America/Los_Angeles,2006,US,-480,0,4,1,0,0,-6:00,10,-1,0,0,-7:00
Which says to me, take effect on the 1st (1) Sunday (0) of April (4) until the last (-1) Sunday (0) in October (10). That suggests the appropriate line for the new U.S. dates would be:
1878,America/Los_Angeles,2007,US,-480,0,3,2,0,0,-6:00,11,1,0,0,-7:00
So, I added that line to the end of the file, but I've been unable to verify whether it works (because of the problem I mentioned above). Can anyone tell me if I'm on the right path?
David Walton
Lane Community College
Adding a new time zone rule to timezones.txt (and related DST issue)
by David Walton -
Number of replies: 16
In reply to David Walton
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Martin Dougiamas -
Looks OK to me ... did you try importing that file?
In reply to Martin Dougiamas
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by David Walton -
Martin,
Thanks for your response!
By import, do you mean "Update complete list of timezones" in Admin > Calendar? I did do that, and It looks like the timezone rule was recognized (it imported the correct number of rules), but I don't think it made any difference vis-a-vis the problem I mentioned above. When I changed the system date to March 12th, the system correctly recognized the timezone (PDT instead of PST), but the availability of quizzes was still off by an hour.
Or...is there an additional process for importing new timezone files that I should have been doing?
Thanks for your response!
By import, do you mean "Update complete list of timezones" in Admin > Calendar? I did do that, and It looks like the timezone rule was recognized (it imported the correct number of rules), but I don't think it made any difference vis-a-vis the problem I mentioned above. When I changed the system date to March 12th, the system correctly recognized the timezone (PDT instead of PST), but the availability of quizzes was still off by an hour.
Or...is there an additional process for importing new timezone files that I should have been doing?
In reply to David Walton
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Dante Leon -
David,
I am going to chime in even though I don't have a programming background. I have observed a similar behavior with Outlook appointments vis a vis DST.
In Outlook the update is a two part process 1)Update the CPU calendar settings so it recognizes the new DST extended period and 2) Update the appointments within that period (3 weeks in March,1 week in November) either manually or through a patch. The reason according to the Outlook web site is that the appointments times/dates are set relative to UTM, so updating the CPU calendar settings does not update the appointments dates/times, they will be off by an hour (MS has a patch for this).
I don't know if the above makes any sense, but probably me might be seeing a similar situation at play with time zones and assignments.
Dante Leon
I am going to chime in even though I don't have a programming background. I have observed a similar behavior with Outlook appointments vis a vis DST.
In Outlook the update is a two part process 1)Update the CPU calendar settings so it recognizes the new DST extended period and 2) Update the appointments within that period (3 weeks in March,1 week in November) either manually or through a patch. The reason according to the Outlook web site is that the appointments times/dates are set relative to UTM, so updating the CPU calendar settings does not update the appointments dates/times, they will be off by an hour (MS has a patch for this).
I don't know if the above makes any sense, but probably me might be seeing a similar situation at play with time zones and assignments.
Dante Leon
In reply to Dante Leon
Re: Adding a new time zone rule to timezones.txt (and related DST issue)Dante,
by David Walton -
Dante,
Thanks for your thoughts. I originally thought that the problem was precisely what you alluded to--the need to update the application's time zone rules to change over to DST on the new U.S. dates. But I'm not sure that's the problem any longer, mostly because the same issue seems to afflict quizzes etc. that are scheduled after April 1st (which would have been the switchover date under the old rules). Yet, the operating system clearly knows about the rules--it switches from PST to PDT just fine at 2:00 AM on March 11th.
Although we're not running Outlook here, we had a similar issue with Groupwise. I'm somewhat glad--from what I've heard, experience with the Outlook application patch hasn't been especially pleasant. I hope you didn't have to spend too much labor on that process. :-|
Thankfully, Moodle stores everything in the database in GMT!
David
Thanks for your thoughts. I originally thought that the problem was precisely what you alluded to--the need to update the application's time zone rules to change over to DST on the new U.S. dates. But I'm not sure that's the problem any longer, mostly because the same issue seems to afflict quizzes etc. that are scheduled after April 1st (which would have been the switchover date under the old rules). Yet, the operating system clearly knows about the rules--it switches from PST to PDT just fine at 2:00 AM on March 11th.
Although we're not running Outlook here, we had a similar issue with Groupwise. I'm somewhat glad--from what I've heard, experience with the Outlook application patch hasn't been especially pleasant. I hope you didn't have to spend too much labor on that process. :-|
Thankfully, Moodle stores everything in the database in GMT!
David
In reply to David Walton
Re: Adding a new time zone rule to timezones.txt (and related DST issue)Dante,
by Dante Leon -
David,
Thanks for the heads up. I was not aware that quizzes due after April 1 are also affected. Our quarter ends this March, so nobody has posted a quiz with a due date beyond March 30.
The Outlook patch worked OK except that I had to be very careful with recurring appointments, those I had to update manually to make sure it was done right.
I'll make a note to keep track of this DST issue in our site coming April.
Dante
Thanks for the heads up. I was not aware that quizzes due after April 1 are also affected. Our quarter ends this March, so nobody has posted a quiz with a due date beyond March 30.
The Outlook patch worked OK except that I had to be very careful with recurring appointments, those I had to update manually to make sure it was done right.
I'll make a note to keep track of this DST issue in our site coming April.
Dante
In reply to David Walton
Re: Adding a new time zone rule to timezones.txt (and related DST issue)Dante,
by Tim Hunt -
It seems that you are running on a Windows server, and that may explain the difference.
On most Unix systems, the underlying clock is set to UTC (GMT), and higher levels of the operating system apply time zone and summer time corrections when displaying the date. Therefore, on Linux, the underlying clock does not change when the change to summer time happens.
On Windows systems, the system clock is normally set to local time, so it does jump when summer time comes in to force.
However, I am not an expert about these things, so I am not sure. Does this explain what you are seeing?
On most Unix systems, the underlying clock is set to UTC (GMT), and higher levels of the operating system apply time zone and summer time corrections when displaying the date. Therefore, on Linux, the underlying clock does not change when the change to summer time happens.
On Windows systems, the system clock is normally set to local time, so it does jump when summer time comes in to force.
However, I am not an expert about these things, so I am not sure. Does this explain what you are seeing?
In reply to Tim Hunt
Re: Adding a new time zone rule to timezones.txt (and related DST issue)Dante,
by David Walton -
Tim,
We're actually running Red Hat ES4. The system timezone is set to America/Los_Angeles. The same behavior is evident whether the system clock is set to use UTC or not. The displayed system date does advance correctly at 2:00 AM on March 11th.
I'm beginning to wonder if there's some other basic problem with the configuration of the time zones or zone data on my server. I'm seeing the same issue with quizzes etc. scheduled after April 1st, which suggests to me that it's got nothing to do with the shift in the start of Daylight Savings Time.
Anyone have any thoughts? Something terribly stupid and obvious that I'm overlooking?
Edit: just as a check, I looked at the date reported by PHP with the date set ahead to April 9:
<?php
echo date("m-d-Y H:i:s T O (Z) I");
?>
That returns "04-09-2007 12:19:31 PDT -0700 (-25200) 1," which matches what I get for the system date (capital I returns 1 if DST is in effect, 0 otherwise). The offset of 25200 seconds calculates to 420 minutes, which matches the -07:00 offset given by date "+%z." The offsets also match when the date is set to March 12th, so we're getting valid offsets on the correct schedule for the DST switch.
David Walton
We're actually running Red Hat ES4. The system timezone is set to America/Los_Angeles. The same behavior is evident whether the system clock is set to use UTC or not. The displayed system date does advance correctly at 2:00 AM on March 11th.
I'm beginning to wonder if there's some other basic problem with the configuration of the time zones or zone data on my server. I'm seeing the same issue with quizzes etc. scheduled after April 1st, which suggests to me that it's got nothing to do with the shift in the start of Daylight Savings Time.
Anyone have any thoughts? Something terribly stupid and obvious that I'm overlooking?
Edit: just as a check, I looked at the date reported by PHP with the date set ahead to April 9:
<?php
echo date("m-d-Y H:i:s T O (Z) I");
?>
That returns "04-09-2007 12:19:31 PDT -0700 (-25200) 1," which matches what I get for the system date (capital I returns 1 if DST is in effect, 0 otherwise). The offset of 25200 seconds calculates to 420 minutes, which matches the -07:00 offset given by date "+%z." The offsets also match when the date is set to March 12th, so we're getting valid offsets on the correct schedule for the DST switch.
David Walton
In reply to David Walton
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Martin Dougiamas -
The dates are stored in GMT in the database and translated to the specified timezone on the fly.
After fixing the timezone calculation you'd still need to go through and fix the dates, because 5pm under the new rules is not the same universal time as 5pm under the old rules.
Other than that does the new rule:
1878,America/Los_Angeles,2007,US,-480,0,3,2,0,0,-6:00,11,1,0,0,-7:00
cover all the DST changes? or do we need a whole lot of new rules for all states?
I'd like to update the central timezone file ASAP so everyone can update to it easily. I've filed MDL-8842 to keep track of it, please post more info there.
After fixing the timezone calculation you'd still need to go through and fix the dates, because 5pm under the new rules is not the same universal time as 5pm under the old rules.
Other than that does the new rule:
1878,America/Los_Angeles,2007,US,-480,0,3,2,0,0,-6:00,11,1,0,0,-7:00
cover all the DST changes? or do we need a whole lot of new rules for all states?
I'd like to update the central timezone file ASAP so everyone can update to it easily. I've filed MDL-8842 to keep track of it, please post more info there.
In reply to Martin Dougiamas
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Martin Dougiamas -
Actually, this should be fixed now ... can people please update their timezone files (it should get them from http://download.moodle.org/timezones) and let me know how it goes? MDL-8842
In reply to Martin Dougiamas
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Anthony Borrow -
I will apply the patch and hopefully all will be taken care. Many thanks for the speedy work.
In reply to Anthony Borrow
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Martin Dougiamas -
For anyone who is a bit confused by the whole timezone thing, just do this:
1.7 and later: Admin > Location > Update Timezones
1.5 and 1.6: Admin > Configuration > Calendar > Update list of timezones ...
1.7 and later: Admin > Location > Update Timezones
1.5 and 1.6: Admin > Configuration > Calendar > Update list of timezones ...
In reply to Martin Dougiamas
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Logan Cox -
I'm not totally sure that it matters, but It looks like the new file is now missing the entries for the US timezone changes in 2006.
In reply to Martin Dougiamas
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Anthony Borrow -
Martin,
I suspect that we would need a new rule for each of the 4 major U.S. time zones (i.e. Eastern, Central, Mountain, Pacific)
Eastern - New York (Los Angeles +3 hours)
Central - Chicago (Los Angeles +2 hours)
Mountain - Denver (Los Angeles + 1 hour)
Pacific - Los Angeles
I would very much appreciate seeing a patched timezone file. The reason for rush is that the time changes this Sunday evening and apparently is just one of those issues that folks have not foreseen. I admit that such things make me dizzy. While I enjoy Star Trek, I get edgy when there is a breach in the time/space continuum. Thanks for your responsiveness to this American issue.
I suspect that we would need a new rule for each of the 4 major U.S. time zones (i.e. Eastern, Central, Mountain, Pacific)
Eastern - New York (Los Angeles +3 hours)
Central - Chicago (Los Angeles +2 hours)
Mountain - Denver (Los Angeles + 1 hour)
Pacific - Los Angeles
I would very much appreciate seeing a patched timezone file. The reason for rush is that the time changes this Sunday evening and apparently is just one of those issues that folks have not foreseen. I admit that such things make me dizzy. While I enjoy Star Trek, I get edgy when there is a breach in the time/space continuum. Thanks for your responsiveness to this American issue.
In reply to David Walton
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by N Hansen -
I have to admit I don't follow this discussion entirely but is the gist of this that those of us with users in the US (and I presume Canada as well) need to update our Moodle files to account for this new rule?
In reply to N Hansen
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Anthony Borrow -
AFAIK you are correct, I found out that on Ubuntu 6.06 all I had to do was verify that things were ready to go (and they were) by using
sudo zdump -v /etc/localtime | grep 2007
and verifying that the following was returned:
/etc/localtime Sun Mar 11 07:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 CST isdst=0 gmtoff=-21600
/etc/localtime Sun Mar 11 08:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 CDT isdst=1 gmtoff=-18000
/etc/localtime Sun Nov 4 06:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 CDT isdst=1 gmtoff=-18000
/etc/localtime Sun Nov 4 07:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 CST isdst=0 gmtoff=-21600
sudo zdump -v /etc/localtime | grep 2007
and verifying that the following was returned:
/etc/localtime Sun Mar 11 07:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 CST isdst=0 gmtoff=-21600
/etc/localtime Sun Mar 11 08:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 CDT isdst=1 gmtoff=-18000
/etc/localtime Sun Nov 4 06:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 CDT isdst=1 gmtoff=-18000
/etc/localtime Sun Nov 4 07:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 CST isdst=0 gmtoff=-21600
In reply to David Walton
Re: Adding a new time zone rule to timezones.txt (and related DST issue)
by Garret Gengler -
I thought I'd post this here to save other folks troubleshooting time. I believe this affects anyone with users in the United States...
This morning, we noticed that calendar events which were scheduled to fall in between March 11 and April 1 2007, were off by one hour. So a 2 pm event would display as 3 pm. Events with dates before March 11 or after April 1 were unaffected. Creating a new event falling between those dates also functioned properly...
Makes sense (eventually) when you think it through. A few weeks back, an instructor creates an assignment, and sets the due date to March 15, 3 pm. Moodle takes that date&time, looks at the time zone rules (including dst if appropriate) for the user's locale, calculates the epoch time, and stores that in the db. Now we change the dst rule set, and what was March 15, 3pm is now March 15, 4 pm.
So... we need to fix the event data. En masse, if possible, without hosing up events that might have been corrected already, or are newly entered...
Here's the query I used to shift all events one hour earlier, that fall in the window of time between the new start of daylight savings and the old one, except for events that have been modified recently (since the rule switch).
mysql>update mdl_event set timestart=timestart-3600 where timestart>1173596400 and timestart < 1175410800 and timemodified<=1173596400;
Additionally, I ran this query to find events that might be affected, but which have been modified recently. For these events, we're contacting the instructors and asking them to confim the times...
mysql> select id,courseid from mdl_event where timestart>1173596400 and timestart < 1175410800 and timemodified>1173596400;
A helpful resource for epoch times, btw, is this web-based calculator... http://www.esqsoft.com/javascript_examples/date-to-epoch.htm
-Garret