## WeBWorK Main Forum

### Timezone woes.

by tom denton -
Number of replies: 13
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.

### Re: Timezone woes.

by Jason Aubrey -
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

### Re: Timezone woes.

by tom denton -

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.pm
• in WeBWorK::ContentGenerator::parseDateTime called at line 1437 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList.pm
• in WeBWorK::ContentGenerator::Instructor::ProblemSetList::saveEdit_handler called at line 387 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList.pm
• in WeBWorK::ContentGenerator::Instructor::ProblemSetList::initialize called at line 196 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator.pm
• in 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...

### Re: Timezone woes.

by Arnold Pizer -
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

### Re: Timezone woes.

by tom denton -
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.

### Re: Timezone woes.

by Arnold Pizer -
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

### Re: Timezone woes.

by tom denton -
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

by tom denton -
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? In reply to tom denton ### Re: Timezone woes. by Danny Glin - 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 In reply to Danny Glin ### Re: Timezone woes. by Arnold Pizer - Hi Danny, If you want to configure the date format, see http://webwork.maa.org/wiki/Dates,_Times,_and_Time_Zones Arnie In reply to tom denton ### Re: Timezone woes. by Tom Merrick - 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. In reply to Tom Merrick ### Re: Timezone woes. by Jason Aubrey - 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

### Re: Timezone woes.

by Tom Merrick -

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.