CVS log for loncom/localize/lonlocal.pm

Up to [LON-CAPA] / loncom / localize

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN
Current tag: bz2851

- reverted changes made in lonlocal.pm 1.58 and lonwhatsnew.pm 1.92
- the root cause for slow performance in lonwhatsnew while looking up received mails
  was found in DateTime::TimeZone's methods for looking up the 'local' timezone:
  [SOURCE: http://search.cpan.org/~drolsky/DateTime-TimeZone-0.90/lib/DateTime/TimeZone/Local/Unix.pm]
  "This class tries the following methods of determining the local time zone:

    * $ENV{TZ}
      It checks $ENV{TZ} for a valid time zone name.

    * /etc/localtime
      If this file is a symlink to an Olson database time zone file (usually in /usr/share/zoneinfo) then
      it uses the target file's path name to determine the time zone name. For example, if the path is
      /usr/share/zoneinfo/America/Chicago, the time zone is "America/Chicago".

      Some systems just copy the relevant file to /etc/localtime instead of making a symlink. In this case,
      we look in /usr/share/zoneinfo for a file that has the same size and content as /etc/localtime to
      determine the local time zone.[...]"

  On our CentOS server /etc/localtime happens to be a copy and this causes TimeZone to do an expensive
  search through the files in /usr/share/zoneinfo (everytime locallocaltime needs the 'local' timezone).
  To prevent TimeZone from doing this search we store the timezone found after the first run in $ENV{TZ}.
  Future calls of locallocaltime will be significantly improved in performance.
  This affects every module that calls locallocaltime (not only lonwhatsnew.pm).