Thanks for your reply. I'm using the 'Timezone' parameter from 'Defaults.pm' because the webserver I'm installing this on has it's local time set to GMT+0 365 days per year. The webserver administrator's reasoning is, "it allows all clients located all over the world to remain unaffected by daylight savings in other countries. Any programs you have should be designed with an offset, so that you can alter the timezone to suit your location's timezone." The result is the time displayed on the OTRS screens is currently ahead by 4 hours relative to the US Eastern Daylight Savings time. In order to display EDT, the Timezone offset parameter in Defaults.pm (or Config.pm) must be set to '-4'. The problem with this is, it causes 'sub CheckSessionID' in 'Kernel::System::AuthSession::IPC' to test 'true' always, thus preventing login by all (admin, agents, and customers). This would also be the case when time goes back to Eastern Standard Time in the Fall, whereby the offset would be set to '-5'. For those in the Pacific timezone, this offset is even 'more negative' relative to GMT+0. In order for the 'CheckSessionID' subroutine to work in the US for all OTRS users when webservers are set to GMT+0 (which is occurring more and more), that calculation has to render 'false' in order to login. I'll look into 'FS' for sessions, but I haven't seen much info on what it is all about. I'd like to know why 'IPC' was chosen over 'FS' as 'default' in 'Defaults.pm' and whether it's because there may be a disadvantage to using 'FS' or whether it's webserver-configuration dependent. If you know, please let me know. I can then modify the displayed time in OTRS to display the time on OTRS screens to the eastern time zone. I'd have to look at the trying to get the tickets' time when submitted to display the eastern time zone versus again, GMT+0. Again, thanks for your response.

Hello again. Here is just a more detailed version of my initial assessment of the cause. Hopefully, it provides some usable information to the final solving of the LOGIN PROBLEM mystery. I believe the problem is located in the following 'equation portion' of the 'if' statement: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # check session idle time my $MaxSessionIdleTime = $Self->{ConfigObject}->Get('SessionMaxIdleTime'); if ( (time() - $MaxSessionIdleTime) >= $Data{UserLastRequest} ) { $Kernel::System::AuthSession::CheckSessionID = 'Session has timed out. Please log in again.'; This routine is located in the following packages: Kernel::System::AuthSession::IPC; Kernel::System::AuthSession::FS; and Kernel::System::AuthSession::DB. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'TimeZone offset' is incorporated in the both 'index.pl' and 'customer.pl' as it defines the 'UserLastRequest' calculated value from 'Kernel::System::Time->System()'. ~~~~~ Since the offset is incorported in the 'UserLastRequest' with respect to the webserver's localtime on the right-hand side of the above equation, and is used in calculating the 'idle time' which is based on the webserver's time in the future, this offset must be incorporated in the time parameter on the left-hand side of the equation so that they'll use the same 'time basis.' As the equation stands, the offset is NOT incorporated on the left-hand side. It only uses the 'raw time', "time()", not the 'corrected time', "time() + offset", as embedded in the equation below: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ time() - $MaxSessionIdleTime) >= $Data{UserLastRequest} ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Therefore, in using the equation above as is, since the timezone offset for the United States, e.g. Eastern time zone, is negative (-4 hrs or -5 hrs; converting to seconds) relative to a webserver whose local time is set at GMT+0, it makes the right-hand side 'equal to' or 'less than' the left-hand side by the value of the offset BEFORE the time has had a chance to elapse when calculating 'idle time.' Then, since the 'SessionMaxIdleTime' is set at 4 hrs., the test of the 'if' statement renders 'TRUE' as soon as the login 'submit' button is clicked. My guess is that time has probably only elapsed some fraction of a second, NOT a whole 1-second to render the statement 'FALSE.' In the strictest sense, as is, the equation is: "time() -14400 >= [time() + elapsed seconds] + (-14400)", whereby, the statement will always render 'TRUE' at login time when 'time()' on both sides of the equation are essentially equal since 'elapsed seconds' essentially equals '0'. This scenario for the Eastern timezone then becomes the point that represents an inflection point for the equation when the 'SessionMaxIdleTime' is set for 4 hrs (14400 sec).

From this, I would think the equation would work if the webserver time at the start is on the same 'basis' as the time at the end, before the 'idle time' is calculated. This would then be for the scenario described above as:

"time() + offset -14400 >= [time() + elapsed seconds] + offset" OR "time() + offset - $MaxSessionIdleTime >= $Data{UserLastRequest}" AND with the numbers mentioned above at login plugged into the equation, "time() -14400 -14400 >= [time() + elapsed second] + (-14400)", WHERE, elapsed seconds = '0' at login. Then, the equation boils down to... "-14400 >= 0", which renders 'FALSE' and allows SUCCESSFUL LOGIN!!! Hope this helps in finding the final solution.

Thank you, Victor. Your info is very helpful.

Hello. NOTE OF CAUTION: If you decide to implement the bugfix in Bug# 719 (re: the revised CVS files), another bug fix is still needed (see Bug# 734) for the complete solution. This new bug fix will actually be implemented in v. 2.0 beta2 therefore, I'm assuming NOT for v.1.3.2 if I interpret the response to Bug# 734 correctly. Take care.