[OPEN-ILS-DEV] Time zones

[Joe Atzberger]

For incoming data the client's notion of what time it is should only matter
for offline circ.  It has to be regarded as otherwise unreliable.  Also the
client can specify local timezones that are not installed or recognizable to
the server.  There is no way around this.  So for new data rows, the
server's version of NOW() is the one that matters.  Evergreen should be
consistent about this already.

For outgoing or display data, datestamp values like due date should be
delivered from the server complete with TZ info if they are being loaded
into a javascript object, sorted by javascript or otherwise interpreted.
 The display of the TZ itself would only be necessary when it differs from
the one the dates are delivered in, but without it the data is ambiguous.

The approach used in Koha (that I think works well there) is to set up a
different VirtualHost for each TZ inferface that needs to be supported and
do something like:

SetEnv TZ "US/Central"


in the config for each one.  See the perldoc, test and underlying
requirements at:

http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=admin/env_tz_test.pl


But that may not be sufficient in Evergreen because of the multi-process
communication going on.  That is to say, each of the different components is
running as a daemon in its own ENV, so one cannot just SetEnv in one place
and for apache expect it to apply to everything.  TZs in EG seems pretty
hairy to me now.  But so did the Koha fix before we figured it out to be
just a couple lines of config and code.... and a big page of documentation.


-joe

On Tue, Jan 11, 2011 at 7:31 PM, James Fournie <
jfournie at sitka.bclibraries.ca> wrote:

> Hi there,
>
> I just wanted to explore something that came up in a previous post by
> Yamil from the Berklee School of Music.  I'm wondering first, if there
> are any other sites with existing ir potential time-zone related
> issues aside from SITKA which has sites in Pacific and Mountain time,
> complicated by the fact that some celebrate daylight savings and
> others do not.
>
> Secondly, I'm wondering what would be involved in making Evergreen
> more compatible with consortia crossing multiple time zones.  We have
> several sites who have minor annoyances due to a typically 1-hour time
> difference, and I'm wondering what we could do to make their
> experience better.  I think due dates are probably the most important
> factor in this regard.   One issue we've noticed is that if items are
> checked out, the due date is generated in the server's time, but then
> when they are displayed in the OPAC, the OPAC converts them to the
> local time zone -- hence Jan 5 23:59 becomes Jan 6th 12:59.  While
> technically accurate, this is not intuitive for patrons.  I've created
> a workaround by just skipping the dojo function which localizes the
> time, but that's obviously a hack and not a good solution.  I'm not
> sure what the best way to begin making the system more time-zone
> friendly would be -- for example, is the best approach to rely on
> client-end time zones, or if it would be better to have an org unit
> setting for cases when a client end time zone is not available?
>
> Anyway, just hashing out some thoughts, I'd like to dig deeper and
> maybe find out where the dates are going to be a problem and what
> dates can just be converted to the local time zone, but I was hoping
> someone else might have some thoughts.
>
> ~James Fournie
> BC SITKA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110116/0bde4776/attachment.htm