Hello!
I'm trying to help a Kenyan math department adopt webwork. (woohoo!) We're running a test-course at the moment, which should help get one of the local lecturers well trained in using webwork, and help us iron out any kinks.
The big kink we've hit so far is that the Africa/Nairobi timezone is producing errors. When saving changes to the due date of a problem set (for example) one gets an error saying that the EAT time zone is not recognized. One can manually remove all of the timezone markers from the due dates and save successfully, but it's quite a pain. Another workaround is to temporarily change the course timezone to America/Toronto, do the required work, and then change back to Africa/Nairobi.
But really there should be some changes to the code base to make things work across all time zones.
Interesting...Africa/Nairobi is a valid tz designator:
http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
So, I would have expected this to work. What sort of errors are you seeing?
Also, I just now switched one of my courses to that timezone and it seems to work just fine. It could be something about your system in particular - if you can show us some error messages it might help.
Jason
http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
So, I would have expected this to work. What sort of errors are you seeing?
Also, I just now switched one of my courses to that timezone and it seems to work just fine. It could be something about your system in particular - if you can show us some error messages it might help.
Jason
Setting the time zone seems to work just fine; it's doing actual work while it's set to Africa/Nairobi that brings trouble. Here's an error message generated after attempting to change one of the problem set due dates by one minute:
Error messages
Time zone 'EAT' not recognized.Call stack
The information below can help locate the source of the problem.
in WeBWorK::Utils::parseDateTime called at line 2039 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator.pmin WeBWorK::ContentGenerator::parseDateTime called at line 1437 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList.pmin WeBWorK::ContentGenerator::Instructor::ProblemSetList::saveEdit_handler called at line 387 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList.pmin WeBWorK::ContentGenerator::Instructor::ProblemSetList::initialize called at line 196 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator.pmin WeBWorK::ContentGenerator::go called at line 371 of /opt/webwork/webwork2/lib/WeBWorK.pm
Removing the EAT from all of the timestamps in the 'edit homework set' page allows it to process correctly, but is kind of a pain...
Hi,
At some point I wrote a detailed explanation of how timezones work but I can't locate it now and don't have time to recreate it.
The main point is assuming the timezone is set correctly in the config file (either system wide or in Course Configuration if different courses are in different timezones), then in some cases you CAN NOT USE the same format to set dates that WeBWorK displays dates in. What you can always do is to not use a timezone when setting a date and WeBWorK will always use the timezone set in the config file. For example when setting a date use
01/01/2005 at 01:00am
NOT
01/01/2005 at 01:00am CST
The short explanation is that timezone abbreviations are not well defined worldwide but some are accepted since they are used so much (and some are not).
Arnie
Hi, Arnie;
Yes, I think I had actually run across that explanation before. Unfortunately, WebWork defaults to including the (in my case) EAT in the date string. Is it possible to change something within webwork so that this abbreviation isn't included in the date string? I'm trying to get the system streamlined such that it can be easily used by a group of lecturers who aren't very tech-savvy.
Yes, I think I had actually run across that explanation before. Unfortunately, WebWork defaults to including the (in my case) EAT in the date string. Is it possible to change something within webwork so that this abbreviation isn't included in the date string? I'm trying to get the system streamlined such that it can be easily used by a group of lecturers who aren't very tech-savvy.
Hi Tom,
The explanation I am talking about is http://webwork.maa.org/wiki/Dates,_Times,_and_Time_Zones
I'm not sure what you mean by " WebWork defaults to including the (in my case) EAT". Do you mean that this happens when instructors try to set a date or when WeBWorK displays a date?
Arnie
When webwork displays a date, including on the homework editor page when trying to change due dates for problem sets, it includes the 'EAT' in the datestamp. (the 'in my case' refers to the EAT; in your case I'm guessing it's CST)
See here for an image:
http://garsia.math.yorku.ca/~sdenton/webworkDatestamp.png
See here for an image:
http://garsia.math.yorku.ca/~sdenton/webworkDatestamp.png
I also tried setting $studentDateDisplayFormat in conf/localOverrides.conf and global.conf (since localOrverrides.conf didn't exist in the conf folder), but it hasn't changed the date display string in the administration view. Is there another variable that might play a similar trick?
You should be able to eliminate the time zone from the admin view by changing line 53 in lib/WeBWorK/Utils.pm from
use constant DATE_FORMAT => "%m/%d/%Y at %I:%M%P %Z";
to
use constant DATE_FORMAT => "%m/%d/%Y at %I:%M%P";
I haven't actually tried this, so I don't know what implications it will have elsewhere.
In fact, I'd like to see this be a configurable option. In our system, all of our students/instructors work in the same time zone, so having the time zone show up there has caused more trouble than benefit. Often when changing a date I forget to account for daylight savings time (by changing MDT to MST), so my times end up off by an hour.
Danny
Hi Danny,
If you want to configure the date format, see http://webwork.maa.org/wiki/Dates,_Times,_and_Time_Zones
Arnie
I think that line 399 in Utils.pm is causing the problem. I think that it is translating the 'EAT' to 'E at'. At least that is my guess.
Tom,
My guess is line 554. If so, then one solution is to edit lib/WeBWorK/Utils.pm. The line:
my $offset = tz_offset($zone, $utc_epoch) or die "Time zone '$zone' not recognized.\n";
Change it to a conditional, maybe something like
if($zone =~ /EAT/i) {
my $offset = 3*60*60; #since EAT is UTC/GMT +3 and offset is in seconds
} else {
my $offset = tz_offset($zone, $utc_epoch) or die "Time zone '$zone' not recognized.\n";
}
That's sort of a hack, but it should work.
Jason
My guess is line 554. If so, then one solution is to edit lib/WeBWorK/Utils.pm. The line:
my $offset = tz_offset($zone, $utc_epoch) or die "Time zone '$zone' not recognized.\n";
Change it to a conditional, maybe something like
if($zone =~ /EAT/i) {
my $offset = 3*60*60; #since EAT is UTC/GMT +3 and offset is in seconds
} else {
my $offset = tz_offset($zone, $utc_epoch) or die "Time zone '$zone' not recognized.\n";
}
That's sort of a hack, but it should work.
Jason
The "error" that I found would only fail for entering the date as '12/31/2012, 9:07am EAT'. The search for changing the comma to an ' at ' should probably preceed the search for changing the 'at' to ' at '.
But your problem is in the Zone.pm file at /usr/share/perl5/Time. There are no african timezones defined here. You probably should contact the authors and get them added for a long term fix. The short term fix would be to add "eat" as an option in this file.
Good call; manually adding a line for 'eat'in /usr/share/perl5/Time/Zone.pm (and then doing an apache restart) seems to have done the trick. Interstingly, there's an entry for west africa, but not east...
I'll see if I can figure out who in the perl upstream to bug about fixing this.
Best,
-tom
I'll see if I can figure out who in the perl upstream to bug about fixing this.
Best,
-tom