Hi,
I am having a bizarre problem configuring the Timezone I want RT to
display in the Web UI. It doesn’t seem to be related to the other issues
I have seen in the archives or wiki.
The system hosting RT has its timezone set to UTC. I want RT to display
the BST timezone for Europe/London (GMT +1) in the web interface and on
emails. I am happy for UTC to continue to be used for all logs and
database entries.
I have added the following line to etc/RT_SiteConfig.pm:
Set( $Timezone , ‘Europe/London’);
I have checked that this is a valid timezone as it exists in
/usr/share/zoneinfo:
ls -la /usr/share/zoneinfo/Europe/London
-rw-r–r-- 7 root root 3661 Jun 20 2009 /usr/share/zoneinfo/Europe/London
I can see this configuration change is loaded correctly when I go to
http:///Admin/Tools/Configuration.html
I have also manually set my users “About Me” preference for timezone to
"Europe/London +0100" from the drop down list.
None of this seems to have any effect on the display of times for
existing tickets in the web ui.
What am I missing? Is there something else I should try?
Here are are the system versions:
RT version: 3.8.6
OS: CentOS release 5.3 (Final)
Kernel: Linux 2.6.18-128.1.16.el5xen #1 SMP Tue Jun 30 06:39:23 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux
Perl: 5.8.8
Apache: httpd-2.2.3-22.el5.centos.1
Is there anything else useful to provide?
Kind Regards,
Kim
The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company.
Hello,
Is it mod_perl? I suspect it’s issue when perl’s ENV is untied from system’s.On Wed, Apr 14, 2010 at 10:07 PM, Kim Covil covilk@lmax.com wrote:
Hi,
I am having a bizarre problem configuring the Timezone I want RT to display
in the Web UI. It doesn’t seem to be related to the other issues I have seen
in the archives or wiki.
The system hosting RT has its timezone set to UTC. I want RT to display the
BST timezone for Europe/London (GMT +1) in the web interface and on emails.
I am happy for UTC to continue to be used for all logs and database entries.
I have added the following line to etc/RT_SiteConfig.pm:
Set( $Timezone , ‘Europe/London’);
I have checked that this is a valid timezone as it exists in
/usr/share/zoneinfo:
ls -la /usr/share/zoneinfo/Europe/London
-rw-r–r-- 7 root root 3661 Jun 20 2009 /usr/share/zoneinfo/Europe/London
I can see this configuration change is loaded correctly when I go to
http:///Admin/Tools/Configuration.html
I have also manually set my users “About Me” preference for timezone to
“Europe/London +0100” from the drop down list.
None of this seems to have any effect on the display of times for existing
tickets in the web ui.
What am I missing? Is there something else I should try?
Here are are the system versions:
RT version: 3.8.6
OS: CentOS release 5.3 (Final)
Kernel: Linux 2.6.18-128.1.16.el5xen #1 SMP Tue Jun 30 06:39:23 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux
Perl: 5.8.8
Apache: httpd-2.2.3-22.el5.centos.1
Is there anything else useful to provide?
Kind Regards,
Kim
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any
way. If you are not a named recipient please notify the sender immediately
and delete any copies of this message. Any unauthorized copying, disclosure
or distribution of the material in this e-mail is strictly forbidden. Any
view or opinions presented are solely those of the author and do not
necessarily represent those of the company.
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Best regards, Ruslan.
Hi Ruslan,
Thanks for the response and apologies for the delay in replying. You are
correct it does seem to be an issue with mod_perl and ENV being untied.
I found another reference to this issue here:
What would be the suggested way of fixing this for our RT installation?
Should I try and write a module as suggested in the above link to
override the localtime functionality?
Regards,
KimOn 14/04/10 20:27, Ruslan Zakirov wrote:
Hello,
Is it mod_perl? I suspect it’s issue when perl’s ENV is untied from system’s.
On Wed, Apr 14, 2010 at 10:07 PM, Kim Covilcovilk@lmax.com wrote:
Hi,
I am having a bizarre problem configuring the Timezone I want RT to display
in the Web UI. It doesn’t seem to be related to the other issues I have seen
in the archives or wiki.
The system hosting RT has its timezone set to UTC. I want RT to display the
BST timezone for Europe/London (GMT +1) in the web interface and on emails.
I am happy for UTC to continue to be used for all logs and database entries.
I have added the following line to etc/RT_SiteConfig.pm:
Set( $Timezone , ‘Europe/London’);
I have checked that this is a valid timezone as it exists in
/usr/share/zoneinfo:
ls -la /usr/share/zoneinfo/Europe/London
-rw-r–r-- 7 root root 3661 Jun 20 2009 /usr/share/zoneinfo/Europe/London
I can see this configuration change is loaded correctly when I go to
http:///Admin/Tools/Configuration.html
I have also manually set my users “About Me” preference for timezone to
“Europe/London +0100” from the drop down list.
None of this seems to have any effect on the display of times for existing
tickets in the web ui.
What am I missing? Is there something else I should try?
Here are are the system versions:
RT version: 3.8.6
OS: CentOS release 5.3 (Final)
Kernel: Linux 2.6.18-128.1.16.el5xen #1 SMP Tue Jun 30 06:39:23 EDT 2009
x86_64 x86_64 x86_64 GNU/Linux
Perl: 5.8.8
Apache: httpd-2.2.3-22.el5.centos.1
Is there anything else useful to provide?
Kind Regards,
Kim
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any
way. If you are not a named recipient please notify the sender immediately
and delete any copies of this message. Any unauthorized copying, disclosure
or distribution of the material in this e-mail is strictly forbidden. Any
view or opinions presented are solely those of the author and do not
necessarily represent those of the company.
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company.
Hello Kim,
Hi Ruslan,
Thanks for the response and apologies for the delay in replying. You are
correct it does seem to be an issue with mod_perl and ENV being untied.
That’s it.
I found another reference to this issue here:
ActiveState Community - Boosting coder and team productivity with ready-to-use open source languages and tools.
What would be the suggested way of fixing this for our RT installation?
Should I try and write a module as suggested in the above link to override
the localtime functionality?
Recently we discovered another issue with mod_perl and starting to
recommend “SetHandler modperl” instead of “SetHandler perl-script”.
Just change the latter to the following:
PerlOptions +GlobalRequest
SetHandler modperl
This will fix issue with timezones on mod_perl 2.x and as well protect
you from other bug. Note that this only works with forking MPM
(usually it’s default setup). For threaded MPMs I suggest to use
FastCGI.
I suggest all people on mod_perl 2 to try it, it’s sligtly faster as well.
Regards,
Kim
Best regards, Ruslan.
Thanks Ruslan,
That fixed it for us.
It has however revealed a different issue.
The date formatter RFC2616 (HTTP) seems to be doing something strange
with the timezone. From lib/RT/Date.pm:
sub RFC2616 {
my $self = shift;
my %args = ( Date => 1, Time => 1,
@_,
Timezone => ‘utc’,
Seconds => 1, DayOfWeek => 1,
);
my $res = $self->RFC2822( @_ );
$res =~ s/\s*[+-]\d\d\d\d$/ GMT/ if $args{'Time'};
return $res;
}
If RFC2822 returns an accurate timezone offset (+0100) this formatter
seems to just strip it and add the letters GMT afterwards. So what we
are seeing is that now timezone processing is correct using
Europe/London we are seeing BST times (GMT+1) with the letters GMT after
them which is incorrect.
Regards,
KimOn 27/04/10 17:10, Ruslan Zakirov wrote:
Hello Kim,
On Tue, Apr 27, 2010 at 6:02 PM, Kim Covilcovilk@lmax.com wrote:
Hi Ruslan,
Thanks for the response and apologies for the delay in replying. You are
correct it does seem to be an issue with mod_perl and ENV being untied.
That’s it.
I found another reference to this issue here:
ActiveState Community - Boosting coder and team productivity with ready-to-use open source languages and tools.
What would be the suggested way of fixing this for our RT installation?
Should I try and write a module as suggested in the above link to override
the localtime functionality?
Recently we discovered another issue with mod_perl and starting to
recommend “SetHandler modperl” instead of “SetHandler perl-script”.
Just change the latter to the following:
PerlOptions +GlobalRequest
SetHandler modperl
This will fix issue with timezones on mod_perl 2.x and as well protect
you from other bug. Note that this only works with forking MPM
(usually it’s default setup). For threaded MPMs I suggest to use
FastCGI.
I suggest all people on mod_perl 2 to try it, it’s sligtly faster as well.
Regards,
Kim
The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company.
It’s a typo in the code 
Replace ->RFC2822( @_ ); with ->RFC2822( %args );On Tue, Apr 27, 2010 at 8:45 PM, Kim Covil covilk@lmax.com wrote:
Thanks Ruslan,
That fixed it for us.
It has however revealed a different issue.
The date formatter RFC2616 (HTTP) seems to be doing something strange with
the timezone. From lib/RT/Date.pm:
sub RFC2616 {
my $self = shift;
my %args = ( Date => 1, Time => 1,
@_,
Timezone => ‘utc’,
Seconds => 1, DayOfWeek => 1,
);
my $res = $self->RFC2822( @_ );
$res =~ s/\s*[±]\d\d\d\d$/ GMT/ if $args{‘Time’};
return $res;
}
If RFC2822 returns an accurate timezone offset (+0100) this formatter seems
to just strip it and add the letters GMT afterwards. So what we are seeing
is that now timezone processing is correct using Europe/London we are seeing
BST times (GMT+1) with the letters GMT after them which is incorrect.
Regards,
Kim
On 27/04/10 17:10, Ruslan Zakirov wrote:
Hello Kim,
On Tue, Apr 27, 2010 at 6:02 PM, Kim Covilcovilk@lmax.com wrote:
Hi Ruslan,
Thanks for the response and apologies for the delay in replying. You are
correct it does seem to be an issue with mod_perl and ENV being untied.
That’s it.
I found another reference to this issue here:
ActiveState Community - Boosting coder and team productivity with ready-to-use open source languages and tools.
What would be the suggested way of fixing this for our RT installation?
Should I try and write a module as suggested in the above link to
override
the localtime functionality?
Recently we discovered another issue with mod_perl and starting to
recommend “SetHandler modperl” instead of “SetHandler perl-script”.
Just change the latter to the following:
PerlOptions +GlobalRequest
SetHandler modperl
This will fix issue with timezones on mod_perl 2.x and as well protect
you from other bug. Note that this only works with forking MPM
(usually it’s default setup). For threaded MPMs I suggest to use
FastCGI.
I suggest all people on mod_perl 2 to try it, it’s sligtly faster as well.
Regards,
Kim
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any
way. If you are not a named recipient please notify the sender immediately
and delete any copies of this message. Any unauthorized copying, disclosure
or distribution of the material in this e-mail is strictly forbidden. Any
view or opinions presented are solely those of the author and do not
necessarily represent those of the company.
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Best regards, Ruslan.
That fixed it, thanks.On 27/04/10 18:20, Ruslan Zakirov wrote:
It’s a typo in the code Replace ->RFC2822( @_ ); with ->RFC2822( %args );
On Tue, Apr 27, 2010 at 8:45 PM, Kim Covilcovilk@lmax.com wrote:
Thanks Ruslan,
That fixed it for us.
It has however revealed a different issue.
The date formatter RFC2616 (HTTP) seems to be doing something strange with
the timezone. From lib/RT/Date.pm:
sub RFC2616 {
my $self = shift;
my %args = ( Date => 1, Time => 1,
@_,
Timezone => ‘utc’,
Seconds => 1, DayOfWeek => 1,
);
my $res = $self->RFC2822( @_ );
$res =~ s/\s*[+-]\d\d\d\d$/ GMT/ if $args{'Time'};
return $res;
}
If RFC2822 returns an accurate timezone offset (+0100) this formatter seems
to just strip it and add the letters GMT afterwards. So what we are seeing
is that now timezone processing is correct using Europe/London we are seeing
BST times (GMT+1) with the letters GMT after them which is incorrect.
Regards,
Kim
On 27/04/10 17:10, Ruslan Zakirov wrote:
Hello Kim,
On Tue, Apr 27, 2010 at 6:02 PM, Kim Covilcovilk@lmax.com wrote:
Hi Ruslan,
Thanks for the response and apologies for the delay in replying. You are
correct it does seem to be an issue with mod_perl and ENV being untied.
That’s it.
I found another reference to this issue here:
ActiveState Community - Boosting coder and team productivity with ready-to-use open source languages and tools.
What would be the suggested way of fixing this for our RT installation?
Should I try and write a module as suggested in the above link to
override
the localtime functionality?
Recently we discovered another issue with mod_perl and starting to
recommend “SetHandler modperl” instead of “SetHandler perl-script”.
Just change the latter to the following:
PerlOptions +GlobalRequest
SetHandler modperl
This will fix issue with timezones on mod_perl 2.x and as well protect
you from other bug. Note that this only works with forking MPM
(usually it’s default setup). For threaded MPMs I suggest to use
FastCGI.
I suggest all people on mod_perl 2 to try it, it’s sligtly faster as well.
Regards,
Kim
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any
way. If you are not a named recipient please notify the sender immediately
and delete any copies of this message. Any unauthorized copying, disclosure
or distribution of the material in this e-mail is strictly forbidden. Any
view or opinions presented are solely those of the author and do not
necessarily represent those of the company.
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company.
I had the same problem, RT 3.8.11. The problem is in rt/lib/RT/Date.pm,
function Localtime (line 971 for me)
The call to localtime ( @local = localtime($unix); ) just doesn’t work,
always returning effectively same as gmtime. All the parameters are correct.
I instead wrote a function using DateTime perl module. However there was a
name clash with a function in the RT file called DateTime and despite there
being code elsewhere in this file that claimed to make use of DateTime
module, I couldn’t get it to work.
So I wrote my own wrapper module exporting function ‘xxLocaltime’ (so I
could find it easily again in future) which had to go in rt/local/lib. This
was able to create DateTime objects, fake the action of localtime perl
builtin and now it works correctly.
Two final notes, there seems to be some problems with the formatting, so I
always choose the system default via the web GUI even though I don’t like it
and I am using mod_perl, but no idea what version, I don’t know how you can
find that out.
View this message in context: http://requesttracker.8502.n7.nabble.com/Problem-configuring-RT-Timezone-tp43488p54555.html