Time Accounting - "Today's Entry" issues with timezones

[brody]

Hi,

We have just installed the OTRS Time Accounting Add-on. Everything is working well in general. However, some of our users want to be able to update their worked upon projects/tasks throughout the day but they have an early start time (6AM) and in our setup the ability to edit the entry for today does not become available until 10AM (until 10AM today appears the same as any day in the future with only the options to set as vacation, sick etc).

At first we assumed that this 10AM was linked to the calendar for the user but we changed calendar settings for working hours and it seemed to have no impact - always a 10AM cut-off.

Is the "current day only available to edit after 10AM" a hard-coded setting? or is it modifiable in some place?

Apologies if I missed some documentation that covers this.

We are using OTRS 3.2.9 and KIX4OTRS and Time Accounting 2.2.1.

Regards,
Brody

[brody]

I looked into this a bit more and it seems to be an issue related to timezone settings. We are running on a machine with UTC as system time and we have an offset of +10 (Sydney, AU).

The entry block on the Edit page for the current day is called the UnitBlock (dtl:block:UnitBlock in AgentTimeAccountingEdit.dtl @ https://github.com/OTRS/TimeAccounting/ ... ngEdit.dtl).

It only gets displayed for this condition being met in @ https://github.com/OTRS/TimeAccounting/ ... ounting.pm.

Code: Select all

        if ( time() > timelocal( 1, 0, 0, $Param{Day}, $Param{Month} - 1, $Param{Year} - 1900 ) ) {
            $Self->{LayoutObject}->Block(
                Name => 'UnitBlock',
                Data => { %Param, %Frontend },
            );
        }

This is using the builtin functions of time and timelocal(). These ignore the +10 offset (they can't have any knowledge of the offset). This results in a failure to open today's entry until after 10AM.

I am not yet sure if the offset is taken care of in the Kernel::System::Time->SystemTime() or not - the name would indicate that it might be the SystemTime and not TZ compensated.

The timelocal function is used quite a few other times also in the file. The style guide points out to not use time/timelocal @ http://otrs.github.io/doc/manual/develo ... guide.html "Use the functions of the TimeObject instead of the builtin functions like time(), localtime() etc."

We can't change our production setup from UTC system time so we'll probably need to make a code change to correct this. I'll look into this but happy if anyone can point out a way that won't require this.

Thanks,
Brody

[crythias]

Please submit a bug report to bugs.otrs.Org

[brody]

Bug created at: http://bugs.otrs.org/show_bug.cgi?id=10494