hours.tt2 does not like examples given for format.time setting

This is a "nice to have" feature. Using the Library Info URL setting in the Library Settings Editor to point to an external web page with hours has been a good workaround for us.

It's more than a "nice to have" feature, as having correctly formatted library structured data (as is otherwise provided in the default library pages, and is unlikely to be provided by pages pointed to using the Library Info URL setting) is required for search engines to be able to accurately determine library contact information, location, and opening hours.

The problem is that the library setting format.time uses Dojo and thus the Unicode date/time formatting patterns, as mentioned here http://dojotoolkit.org/reference-guide/1.9/dojo/date/locale/format.html and http://unicode.org/reports/tr35/tr35-6.html#timeFormats, while the TPAC pages use the Template::Plugin::Date module and thus the POSIX strftime date/time formatting patterns, as mentioned here: http://www.template-toolkit.org/docs/modules/Template/Plugin/Date.html

These are clearly not compatible formats, as Jason pointed out.

We should probably do three things:

1) Clearly document that the format.time library setting uses the Unicode date/time formatting patterns so that libraries have a better idea of what they should enter to provide a valid non-default setting for the staff client, and note that it is only used by the staff client;

2) Use a simple config.tt2-settable TIME_FORMAT setting for the human-readable version that mirrors how we currently make it possible to override the default DATE_FORMAT setting for the TPAC;

3) We should provide the machine-readable times in hh:mm:ss[Z|(+|-)hh:mm] format per http://schema.org/Time via a @content attribute on the HTML element, and might as well turn that HTML element into a <time> element instead of a meaningless <span> element.

Pushed http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbs/lp1326149_library_hours_display which addresses #2 and #3, thus resolving the core errors.

Perhaps we should leave #1 to a separate bug as it is truly a nice-to-have, whereas #2 and #3 are potentially very real runtime problems.

Picked to master and rel_2_6. Thanks Dan!