Closed Bug 604942 Opened 14 years ago Closed 10 years ago

Getting the message 'undef error - Cannot determine local time zone' while searching and while submitting a new bug

Categories

(Bugzilla :: Bugzilla-General, defect)

Product:
Bugzilla
Component:
Bugzilla-General
Platform:
x86_64
FreeBSD
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: yuri, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.10) Gecko/20100930 Firefox/3.6.10
Build Identifier: 

I already files the similar PR#559604. But it got marked as duplicate of some other PR, which in turn got marked as a duplicate of another PR which is marked fixed. But this problem still exists in bugzilla-3.6.2 on FreeBSD-8.1-STABLE.

When I hit 'Search' in 'Advanced Search' screen (/bugzilla/query.cgi?format=advanced) I get this red message:
undef error - Cannot determine local time zone
Advice feom here: http://old.nabble.com/undef-error---Cannot-determine-local-time-zone-td19433162.html still helps and adding "BEGIN { $ENV{TZ} = 'America/Denver' }" fixed the problem.

This problem exists for way too long and should be fixed.


Reproducible: Always
Summary: Getting then message 'undef error - Cannot determine local time zone' while searching and while submitting new bug → Getting the message 'undef error - Cannot determine local time zone' while searching and while submitting a new bug
What's the output of:

perl -MDateTime::Locale -we 'print $DateTime::Locale::VERSION'

(you must run it from the command-line)

Anyway, this very likely means you don't have all the required dependencies installed correctly.
0.45

Which dependency can cause such behavior?
If this is the case the problem is in FreeBSD ports since I reinstalled system from scratch and this behavior still there.
Thanks for the bug report. I understand how frustrating this can be.

This indicates some problem with the configuration of your system--either there are some dependencies that are not installed, or your /etc/localtime file does not actually come from your current tzdata package (set the timezone on your server, again).
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Looks like /etc/localtime was outdated. I regenerated it with tzupdate and now the problem is gone.
I'm seeing this problem on multiple systems running Ubuntu 13.10.   It is happening with both bugzilla-4.2.3 and bugzilla-4.4.2.  

perl -MDateTime::Locale -we 'print $DateTime::Locale::VERSION'
reports version 0.45

I removed /etc/localtime and regenerated it with 
sudo dpkg-reconfigure tzdata
Unfortunately that appears to have no effect.

In the bugzilla administration, I updated the "Timezone used to display dates and times" to a specific value other than "Same as server".  That didn't seem to help.

In the bugzilla administration parameters index, I don't see any setting I can tweak related to timezone.

What else should I be trying?
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
This is a problem with DateTime, not with Bugzilla.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 10 years ago
Resolution: --- → INVALID
If it matters, my timezone is set to America/New_York.  This causes /etc/localtime to be a copy of /usr/share/zoneinfo/posixrules which is what is symlinked from /usr/share/zoneinfo/America/New_York.

I can confirm that editing the file Bugzilla/Util.pm in the bugzilla installation directory and adding the line 
BEGIN { $ENV{TZ} = 'America/New_York' } 
right after the lines 
use Date::Parse;
use Date::Format;
does cause the problem to go away.
This is a error is generated from DateTime::TimeZone::Local, which is somehow failing due to system configuration. On a Unixy platform, that module will search (in order)

  * $ENV{TZ}
  * /etc/localtime (by comparing file content to /usr/share/zoneinfo)
  * /etc/timezone (a text file containing the time zone on one line)
  * /etc/TIMEZONE (looking for TZ=TimeZone/Name)
  * /etc/sysconfig/clock (a redhat-ism)
  * /etc/default/init (looking for TZ=TimeZone/Name) 


To help figure out DateTime::TimeZone::Local is not working on your system, the following 
one-liner will print out the detected time zone or die trying:

perl -MDateTime::TimeZone::Local -le 'print DateTime::TimeZone::Local->TimeZone()->name'

If you think this is still a bug, you could report it to the maintainers for DateTime-TimeZone
using the following link: https://rt.cpan.org/Public/Dist/Display.html?Name=DateTime-TimeZone

Best of luck! 

(and hopefully this comment will be useful to future people the re-encounter this problem).
Your one liner does print out the correct information ("America/New_York" in my case).  This appears to come from my /etc/timezone file which has this information.

I suspect that Bugzilla is somehow unsetting the timezone in such a way the prevents the DateTime module from working.  

One reason that I suspect this is that I experimented with getting the TZ environment variable set for Bugzilla from the Apache configuration.    Adding the line 
SetEnv TZ America/New_York
in my bugzilla virtual host configuration did not cause bugzilla to work as expected.  The only work around that I have found that works is modifying the Bugzilla/Util.pm file.
Interesting! From the bugzilla install directory, what does this output?

perl -MBugzilla -le 'print Bugzilla->local_timezone->name
Also fine (after adding the closing quote to the command):

~/sites/bugzilla/bugzilla$ perl -MBugzilla -le 'print Bugzilla->local_timezone->name'
America/New_York
But that is with the workaround, in place, let me remove it and try again.
I commented out the BEGIN {$ENV{TZ}="America/New_York"} line from Bugzilla/Util.pm that I had in and tried again, it still reports the correct "America/New_York" timezone.
Things are working without the workaround on this machine all the time now.  I'm not sure what is different from yesterday.    I have three boxes that were exibiting this behavior.  Let me log onto those and see if all of them are behaving the same way.  This is the only one on which I reconfigured the timezone yesterday.
OK, I have a server in a state in which it exhibits the bug again.  Here is a link: http://bugzilla.deadsea.ostermiller.org/buglist.cgi?bug_status=NEW&product=ContactForm
"Software error: Cannot determine local time zone"

On that machine, I can run this command:
~/sites/bugzilla/bugzilla$ perl -MBugzilla -le 'print Bugzilla->local_timezone->name'
America/New_York
To rule out any permissions problems, I su to the www-data user (which is what Apache runs as on Ubuntu) and ran that command as that user with the same results:

$ perl -MBugzilla -le 'print Bugzilla->local_timezone->name'
America/New_York

It still could be an issue with Apache configuration.  Maybe there is some needed piece of information that isn't getting passed into Bugzilla when run through Apache?
I can confirm that there is something different when running as CGI inside Apache vs running from the command line.  index.cgi with:

use DateTime::TimeZone::Local;
$vars->{'tz'} = DateTime::TimeZone::Local->TimeZone()->name;

I get the "Software error: Cannot determine local time zone" when visiting the home page of Bugzilla then.

Same behavior if I modify index.cgi with

$vars->{'tz'} = Bugzilla->local_timezone->name;
It has something to do with Bugzilla's use of the -T flag.  If I change the line
#!/usr/bin/perl -wT
to
#!/usr/bin/perl -w
then bugzilla is able to determine the timezone without problem.
perl -T -MDateTime::TimeZone::Local -le 'print DateTime::TimeZone::Local->TimeZone()->name' 
fails on my systems.

This appears to be because the DateTime library reads the /etc/timezone file which causes this data to be "tainted".  It then calls _IsValidName on that data to validate it.  This does not however "untaint" the variable.   When it tries to contruct a new variable with this tainted variable, it does so using 
return eval { DateTime::TimeZone->new( name => $name ) }
which returns NULL in taint mode when $name is tainted.
I think that also explains why setting the $ENV{TZ} variable from inside bugzilla is a valid workaround, but setting it from Apache is not:  It is only tainted when it is set from Apache.
I wonder why it fails to find your /etc/localtime against /usr/share/zoneinfo.
Nevertheless, I think not de-tainting /etc/timezone data is incorrect behavior -- a bug should be filed on DateTime-TimeZone's RT.
This problem was fixed in DateTime::TimeZone 1.64

Looking at the Bugzilla documentation it appears that Bugzilla only requires version 0.71 of DateTime::TimeZone  This requirement should be updated to 1.64 because of this bug.

checksetup.pl should also check to make sure that DateTime::Timezone is at version 1.64 or later.
See Also: → 803201
(In reply to Stephen Ostermiller from comment #24)
> checksetup.pl should also check to make sure that DateTime::Timezone is at
> version 1.64 or later.

See bug 803201.
When I run  ./checksetup.pl
it is starting like this
This is Bugzilla 4.4.5 on perl 5.10.1
* Running on Linux 2.6.32-305-ec2 #9-Ubuntu SMP Thu Apr 15 08:05:38 UTC 2010

But when i run date in command line
Mon Oct 13 18:25:38 IST 2014

So where bugzilla checksetup script is taking time from?
I could see bugzilla home page and everything. But when I submit a bug after 
enter all details it says "Cannot determine local time zone"
Kindly help me on this to come out from this issue
(In reply to bizlemapp from comment #26)
> Kindly help me on this to come out from this issue

Please see http://www.bugzilla.org/support/ for support requests. Thanks.
Hi,

In case some is still having this problem, I was getting the same error with a Bugzilla 4.4.8 running on ActivePerl 5.20.1, MySQL 5.6 and Windows 8 (Non english Version). My workaround was the following:

1) Open Local.pm file from DateTime perl Module under \site\lib\DateTime\TimeZone\ (C:\Perl64\site\lib\DateTime\TimeZone for default Windows install of ActivePerl).

2) Go to TimeZone method and comment all lines, add this new one:

 return DateTime::TimeZone->new(name => 'America/Bogota');

 Where America/Bogota should be replaced with your own timezone, you can get it from http://search.cpan.org/dist/DateTime-TimeZone/lib/DateTime/TimeZone/Catalog.pm


3) Retry reproducing the problem, above steps worked for me.


While digging for a solution I was able to find the following in case someone wants to dig deeper:

- It seems for non-english installations of Windows the system registry that holds TimeZone information pointing to a DLL instead of saving the actual name of the timezone under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\.

- It seems DateTime module gets timezone information from OS, which in this case points to an invalid string since it says "@tzres.dll,NNN" which causes the perl code from DateTime module to throw an exception which in turn is passed up and shown on the error message while attempting to create a bug.



Hope it helps someone since it took me a while to find the workaround.

Thanks!


Javier
In my case of this error (on Win2008Server) I installed "DateTime-TimeZone-Local-Win32" package and the problem was gone.
Yes, problem in packages configuration. "DateTime", "DateTime-Locale" and "DateTime-TimeZone" package list is not enough for correct work of bugzilla. Install "DateTime-TimeZone-Local-Win32" package for correct work.
Fix it and make a patch. They themselves apparently failed to fix it and closed the problem, but the problem is still there.
Confirming this still exists on my installation:

C:\bugzilla>checksetup.pl
* This is Bugzilla 4.4.9 on perl 5.20.2
* Running on Win7 Build 7601 (Service Pack 1)

Checking perl modules...
Checking for               CGI.pm (v3.51)     ok: found v3.65
Checking for           Digest-SHA (any)       ok: found v5.95
Checking for             TimeDate (v2.23)     ok: found v2.24
Checking for             DateTime (v0.28)     ok: found v1.18
Checking for    DateTime-TimeZone (v0.79)     ok: found v1.90
Checking for                  DBI (v1.614)    ok: found v1.633
Checking for     Template-Toolkit (v2.22)     ok: found v2.26
Checking for           Email-Send (v2.16)     ok: found v2.201
Checking for           Email-MIME (v1.904)    ok: found v1.929
Checking for                  URI (v1.37)     ok: found v1.67
Checking for       List-MoreUtils (v0.32)     ok: found v0.406
Checking for    Math-Random-ISAAC (v1.0.1)    ok: found v1.004
Checking for                Win32 (v0.35)     ok: found v0.51
Checking for            Win32-API (v0.55)     ok: found v0.80


Installed DateTime-TimeZone-Local-Win32 as suggested above (ppm install DateTime-TimeZone-Local-Win32), fixed the issue.
(In reply to Yuri from comment #31)
> Fix it and make a patch. They themselves apparently failed to fix it and
> closed the problem, but the problem is still there.

This bug was not about Windows, but about a taint issue in DateTime, see comment 25. This problem has been fixed one year ago.

Your specific problem about the missing DateTime::TimeZone::Local::Win32 module on Windows has been fixed in bug 1124401 a few days ago.
I was able to recover from this error by upgrading my DateTime::TimeZone from 1.58 to 1.96, as suggested in Comment #24. In Bugzilla 4.4.11, checksetup.pl only requires version 0.71 for some reason.
You need to log in before you can comment on or make changes to this bug.