[Phpgroupware-tracker] [Bug #1672] Timestamps & Database issues

[nobody]

=================== BUG #1672: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=1672&group_id=509

Changes by: Chris Weiss <address@hidden>
Date: Tue 03/18/03 at 15:17 (America/Chicago)

------------------ Additional Follow-up Comments ----------------------------
i can help with #1, I spent way too long figuring this out only to decide it 
needs either completly scrapped and replaced with a manual server pref or the 
guy who wrote it needs to surface and explain what he was going for so it can 
be fixed.

In short, unless your server is set to GMT the tz offset for the server will be 
doubled.  Here is a sort of fix, though it's really anoying and gets wiped out 
if you change any setup/config step2 info:
Set the port to 00 - disabled, then save.  Before doing anything at all edit 
the phpgw_config table and set the tz_offset item to 0 (it will be your actual 
time zone offset from GMT, which the datetime class then subtracts from the 
server time).

/me wonders off grumbling after realizing his setting got set back to -6 again



=================== BUG #1672: FULL BUG SNAPSHOT ===================


Submitted by: biker                   Project: phpGroupWare                 
Submitted on: Sun 11/10/02 at 14:40
Category:  API - phpGWapi             Bug Group:  0.9.14 release            
Severity:  5 - Major                  Priority:  None                       
Resolution:  None                     Assigned to:  None                    
Status:  Open                         Component Version:  None              
Platform Version:  Linux - RedHat     Reproducibility:  Every Time          

Summary:  Timestamps  & Database issues

Original Submission:  I am running  phpgroupware 0.9.14 and have run the cvs 
update so that groupware will run under Apache 2.0.40 (see bug on registration 
and login pages not working(#1420 I believe) and are still having some problems 
with the system.

1) We have a problem with Timestamps on posts. The whole redhat 8 system is 
synced and set to MST (Arizona) timezone. Redhat and system time work fine 
using ntp. Groupware is setup to use port 13 but we have tried disapled (00) 
and http (80). Setting the timezone offset value appears to work erradically, 
but never stablizes on the same time. I have tried several offset values (-7 
which is MST in several other ntp implementations I am accustomed to) but to no 
avail. It's always right on the minutes, just a wrong hour.

2)Unless DB-Type is set to 'db' instead of PHP4 (for better performance) the 
user session management aspects do not appear to work. The 'current users' 
feature for admins always shows 0 and no session log data is available. 
Incidently, back to the time issue in this section, the login times and post 
timestamp times do both change as setting timezone offset value changes, but 
the two times never correspond with each other) 

3) Speed Issues: It is a relatively small system, roughly 40 users and maybe a 
max of 5 to 10 simultaneous. When getting more than 1 or 2 users, performance 
really drops. Using pgsql 7.2.2-1 on redhat 8. Is there some tuning that can be 
done to pgsql to speed groupware up? The machine is a Pentium class 300mhz with 
256 mb RAM and login times are 30-45 seconds with a single user. Screen changes 
are 15 seconds or so. This drops significantly with more than 2 users.



Follow-up Comments
*******************

-------------------------------------------------------
Date: Tue 03/18/03 at 15:17         By: cw
i can help with #1, I spent way too long figuring this out only to decide it 
needs either completly scrapped and replaced with a manual server pref or the 
guy who wrote it needs to surface and explain what he was going for so it can 
be fixed.

In short, unless your server is set to GMT the tz offset for the server will be 
doubled.  Here is a sort of fix, though it's really anoying and gets wiped out 
if you change any setup/config step2 info:
Set the port to 00 - disabled, then save.  Before doing anything at all edit 
the phpgw_config table and set the tz_offset item to 0 (it will be your actual 
time zone offset from GMT, which the datetime class then subtracts from the 
server time).

/me wonders off grumbling after realizing his setting got set back to -6 again

-------------------------------------------------------
Date: Sun 11/24/02 at 10:04         By: biker
The timestamps are our main issue with this bug report. Adding RAM helped most 
of the applications (email is still slow, but it's also going out to an 
external server over the web to get mail via IMAPS.
Where the timestamps are concerned, it doesn't seem to matter what settings I 
try, I can not get timestamps to coincide with the system time. We are located 
in Arizona and it always appears 7 hours hehind the system time for posts in 
the forums, calendar and other areas that show timestamps. Email seems to be 
the only application that shows the correct time and that is probably due to 
the fact that it is hitting an external mail server located elsewhere on our 
domain and not related to (or even running) phpgroupware.
Any help on this issue would be greatly appreciated.

-------------------------------------------------------
Date: Tue 11/12/02 at 17:08         By: skwashd
1) I am not sure about why this is happening

2) At the moment it is not possible to show current users under php4 sessions.  
I doubt the access log will ever show the user activity as it is designed not 
to use the db at all.

3) If you want a lot of activity i would suggest a serious server.  I used to 
run a 2xPIII-866 with 256M RAM and 2x40G HDD RAID 1.  It was slow but with 1G 
RAM it hums.  RAM RAM RAM and a gutsy processor would be my adivce.

Hope this helps


CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=1672&group_id=509