Time-zone name in set definition files can be invalid "short time-zone names" and prevent importing the file

[taniwallach]

I am doing testing with the UTF8 support from #927 and ran into an issue with a set definition file (SDF below) which had been created in a course whose time-zone is set to Asia/Jerusalem.

The SDF which listed the assignment times using the "short" time zone string "IST" (from the use "%Z" in the format string used to generate the date/time string) as follows:

openDate          = 03/06/2019 at 11:59pm IST
reducedScoringDate = 03/13/2019 at 11:59pm IST
dueDate           = 03/13/2019 at 11:59pm IST
answerDate        = 03/15/2019 at 11:59pm IST

Trying to import this SDF into a different course failed, and triggers the error messages given at the bottom of the post.

The simple workaround was to delete the " IST" from these lines, after which the SDF could be imported.

In the long run, generating set definition files which cannot be imported without manually being fixed seems to be something we would like to avoid.

This issue is related to what was handled in #900 which fixed a similar problem creating assignments, as the process used a "%Z" short time-zone string in the middle of the process which caused adds assignments, and that intermediate use of "%Z" was was removed.

Fixing the issue for SDF files is more complex. The complexity really is only an issue if there is a real need to include time-zone information in the files. If not, the fix would be to simply leave it out.

Some options are:

• Just drop the inclusion of a time-zone string when a SDF is generated.
• Add an checkbox to control whether or not to including the time-zone in a generated SDF (probably default to off, which should be fine for most users).
• Use the "%{time_zone_long_name}" format string to include the "long" time zone name, which is unique and should not trigger errors during parsing.
• Add a course-wide option to toggle SDF generation to use the course configuration time-zone (string) value instead of "%Z" in the date-time format used when generating a SDF.
• Use "%z" to give the time-zone via a UTC offset.
  • This can somewhat confusing when dates in a SDF are hand-edited, as the local offset will change between winter/summer time, so I personally think this is probably the least convenient option for users - even if that is what ISO standards (and RFC822) may recommend/require using.

Note: Any change will need to be in both the code which exports the SDF and the code which imports an SDF.

See: https://metacpan.org/pod/DateTime from which the following bits were pulled:

strftime Patterns
The following patterns are allowed in the format string given to the $dt->strftime() method:

%z    The time-zone as hour offset from UTC. Required to emit RFC822-conformant dates (using "%a, %d %b %Y %H:%M:%S %z").

%Z    The time zone or name or abbreviation.


$dt->time_zone_long_name()
This is a shortcut for $dt->time_zone->name. It's provided so that one can use "%{time_zone_long_name}" as a strftime format specifier.

$dt->time_zone_short_name()
This method returns the time zone abbreviation for the current time zone, such as "PST" or "GMT". These names are not definitive, and should not be used in any application intended for general use by users around the world.

---

Error messages

    Time zone 'IST' not recognized. 

Call stack

The information below can help locate the source of the problem.

    in WeBWorK::Utils::parseDateTime called at line 2255 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator.pm
    in WeBWorK::ContentGenerator::parseDateTime called at line 1982 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList2.pm
    in WeBWorK::ContentGenerator::Instructor::ProblemSetList2::readSetDef called at line 1720 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList2.pm
    in WeBWorK::ContentGenerator::Instructor::ProblemSetList2::importSetsFromDef called at line 1339 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList2.pm
    in WeBWorK::ContentGenerator::Instructor::ProblemSetList2::import_handler called at line 404 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList2.pm
    in WeBWorK::ContentGenerator::Instructor::ProblemSetList2::initialize called at line 231 of /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator.pm
    in WeBWorK::ContentGenerator::go called at line 384 of /opt/webwork/webwork2/lib/WeBWorK.pm
 which cannot be handled on import.

[taniwallach]

The fatal error message Time zone ??? not recognized. is created in lib/WeBWorK/Utils.pm on line 615:

my $offset = tz_offset($zone, $utc_epoch) or die "Time zone '$zone' not recognized.\n";

I am proposing a workaround in #941 which falls back to the $display_tz sent to the function or the local timezone.

[taniwallach]

The fall-back code in #941 is intended to "solve" this issue to a reasonable extent for WW 2.15.

The question of whether or not and how to include a time-zone string in set definition files remains open, but is far less urgent to consider after the changes from the PR.