The issue turned out to be a bug with ActivePerl's PerlEx.  It doesn't seem
to apply the timezone setting if you change it within config.pm (or anywhere
else, for that matter).

I had even started explicitly calling tzset() in Config.pm and still there
was no effect on locatime or timelocal.

$ENV{'TZ'} = 'UTC';
POSIX::tzset();

Hugh

On Sat, Aug 28, 2010 at 11:33 AM, Hugh Kelley <[email protected]> wrote:

> More updates.
>
> First, I now realize that the the TimeZoneUser and
> TimeZoneUserBrowserAutoOffset options must both be enabled.  I had thought
> they were unlinked.  From InterfaceAgent.pm:
>
>             $Self->{ConfigObject}->Get('TimeZoneUser')
>             && $Self->{ConfigObject}->Get('TimeZoneUserBrowserAutoOffset')
>             && $LayoutObject->{BrowserJavaScriptSupport}
>
> Setting both, I now see calculations occurring in the UI.  Unfortunately,
> they are occurring twice.  For example:
>
> From the ticket_history table in the DB (UTC time)
>
>      id    ticket_id    article_id    create_time
>      685    57    166    2010-08-26 04:04:18.373
>
> From the UI (indicates a -4 offset but calculates a -8):
>
>      Created:    08/25/2010 20:04:18 (-4)
>
> I have tried this with and without the   $ENV{'TZ'} = 'UTC';   option in
> config.pm.  The UI is the same either way.
>
> I assume this double counting is occurring because both the back end and
> the presentation layers are calculating.  I need to stop the back end
> calculations and have the server side simply rely on the UTC timestamps from
> the database.
>
> Is there an authoritative document I should be reading to understand OTRS'
> time treatment?  I'm getting a bit confused here because I feel like my
> findings don't match this guidance,
> http://faq.otrs.org/otrs/public.pl?Action=PublicFAQ&ItemID=335.
>
> Hugh
>
>
>
> On Thu, Aug 26, 2010 at 6:08 PM, Hugh Kelley <[email protected]>wrote:
>
>> I am using the forms-based auth and I do see the TimeOffset hidden
>> variable being posted at login.
>>
>>
>> Action=Login&RequestedURL=Action%3DAgentDashboard&Lang=en&TimeOffset=120
>>
>> My Core::Time is at the default, other than this:
>>
>>      delete $Self->{'TimeZoneUser'};
>>
>> config.pm is setting the server to UTC (and I used a quick Perl script
>> outside of OTRS to confirm that the ActiveState interpreter works with this
>> command)
>>
>>     $ENV{TZ}='UTC';
>>
>> And finally, the database show the following UTC for my test article's
>> create_time:
>>
>>      2010-08-26 11:37:20.050
>>
>> Yet the UI insists on showing it as EDT (-4) (which is the local time zone
>> of the web server).
>>
>>      08/26/2010 07:37:19
>>
>> I would be grateful for any diagnostic hints.
>>
>> Hugh
>>
>>
>>
>> On Thu, Aug 26, 2010 at 6:27 AM, Michiel Beijen 
>> <[email protected]>wrote:
>>
>>> Hi Hugh,
>>>
>>> That's an in-depth analysis...
>>>
>>> Could it be that you use Single Sign On? Because, in that case we
>>> don't get the timezone information from the browser. We have an open
>>> bug report for that:
>>>
>>> http://bugs.otrs.org/show_bug.cgi?id=5429
>>>
>>> --
>>> Michiel Beijen
>>> Senior Consultant
>>>
>>> OTRS BV
>>> Schipholweg 103
>>> 2316 XC  Leiden
>>> The Netherlands
>>>
>>> T: +31 71 8200 255
>>> F: +31 71 8200 254
>>> I:  http://www.otrs.com
>>>
>>> OTRS brings true mobility to the Help Desk: The OTRS iPhone App free
>>> download http://www.otrs.com/en/products/iphone-app/
>>>
>>>
>>> On Thu, Aug 26, 2010 at 6:35 AM, Hugh Kelley <[email protected]>
>>> wrote:
>>> > I spoke too soon.  This was already anticipated by the developers.
>>> >
>>> > If you are running on MS SQL Server, see Kernel/System/DB/mssql.pm,
>>> line 50:
>>> >
>>> >       # set current time stamp if different to "current_timestamp"
>>> >       $Self->{'DB::CurrentTimestamp'} = 'SYSUTCDATETIME()';
>>> >
>>> > This will perform a replacement of "CURRENT_TIMESTAMP", as desired in
>>> my
>>> > case.
>>> >
>>> > Now I need to concentrate on the client-side detection.  Neither
>>> Firefox nor
>>> > IE is sending any timezone related headers.
>>> >
>>> > On Wed, Aug 25, 2010 at 8:13 PM, Hugh Kelley <[email protected]>
>>> wrote:
>>> >>
>>> >> I've dug into this a bit further and can offer this:
>>> >>
>>> >> First, the OTRS code itself is inserting time stamps in the database
>>> as
>>> >> local (to the database server) time.
>>> >>
>>> >> From Ticket.pm:
>>> >>
>>> >>         SQL => "INSERT INTO time_accounting "
>>> >>             . " (ticket_id, article_id, time_unit, create_time,
>>> create_by,
>>> >> change_time, change_by) "
>>> >>             . " VALUES (?, ?, $Param{TimeUnit}, current_timestamp, ?,
>>> >> current_timestamp, ?)",
>>> >>
>>> >> For this to put proper UTC times in the database it would need to
>>> change
>>> >> from CURRENT_TIMESTAMP to:
>>> >>
>>> >>     SQL Server:      SYSUTCDATETIME
>>> >>     MySQL:            UTC_TIMESTAMP
>>> >>
>>> >> Since there is no true cross-platform function for UTC time, it would
>>> seem
>>> >> most safe to add a user-defined function to the OTRS DB like
>>> >> OTRS_SYS_TIME.  In SQL Server, creating a UDF is a trivial matter.  I
>>> think
>>> >> MySQL is a bit trickier as it requires a C-style implementation, which
>>> >> introduces a few more OS cross-compatibility issues.
>>> >>
>>> >> Is this just a problem for Windows DB implementations?  Does MySQL on
>>> a
>>> >> Linux distro behave differently?  Is this not an issue for most OTRS
>>> users?
>>> >> I see UTC-based time referencing as critical for my implementation
>>> (support
>>> >> across 9 time zones, a need to do integration with/reporting from the
>>> >> database, etc.), but I may be in the minority.
>>> >>
>>> >> Hugh
>>> >>
>>> >>
>>> >> On Tue, Aug 24, 2010 at 4:49 PM, Hugh Kelley <[email protected]>
>>> >> wrote:
>>> >>>
>>> >>> Our staff work in multiple time zones so I need to store all ticket
>>> data
>>> >>> in UTC.
>>> >>>
>>> >>> I believe I have identified the options I want:
>>> >>>
>>> >>> - On the server, include     $ENV{TZ}='UTC';   in config.pm
>>> >>>
>>> >>> - In the SysConfig, Core::Time , TimeZoneUserBrowserAutoOffset is set
>>> to
>>> >>> Yes
>>> >>>
>>> >>> From what I can see, the $ENV{TZ}='UTC'; setting is not taking effect
>>> in
>>> >>> my environment.
>>> >>>
>>> >>> - Windows Server 2008
>>> >>> - ActiveState Perl
>>> >>>
>>> >>>
>>> >>> Has anyone seen this configuration work before?  Is there a page in
>>> OTRS
>>> >>> that shows the "system clock"?
>>> >>>
>>> >>> Hugh
>>> >>
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > OTRS mailing list: otrs - Webpage: http://otrs.org/
>>> > Archive: http://lists.otrs.org/pipermail/otrs
>>> > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>>> >
>>> ---------------------------------------------------------------------
>>> OTRS mailing list: otrs - Webpage: http://otrs.org/
>>> Archive: http://lists.otrs.org/pipermail/otrs
>>> To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
>>
>>
>>
>
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs

Reply via email to