[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: nobody
Subject: [Phpgroupware-tracker] [Bug #1672] Timestamps & Database issues
Date: Sat, 03 May 2003 04:48:51 -0400

=================== BUG #1672: LATEST MODIFICATIONS ==================

Changes by: Ralf Becker <address@hidden>
Date: Sat 05/03/2003 at 10:48 (Europe/Berlin)

            What     | Removed                   | Added
              Status | Open                      | Closed

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

Submitted by: biker                   Project: phpGroupWare                 
Submitted on: Sun 11/10/2002 at 21:40
Category:  API - phpGWapi             Bug Group:  0.9.14 release            
Severity:  5 - Major                  Priority:  None                       
Resolution:  None                     Assigned to:  ralfbecker              
Status:  Closed                       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: Fri 03/21/2003 at 02:42       By: ralfbecker
This has been corrected in CVS.

To grab a complete update of all fixes:

1)  Check to see if you have cvs installed: 'cvs --help'.
1a) If not, install a copy of cvs-cli from your favorite 

2)  Then just type:
    'cd <your phpgroupware dir>; cvs update -dP'.

You can do step 2 as many times in a day as you wish, and 
will always get the most current bug fixes.


Date: Tue 03/18/2003 at 22: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/2002 at 17: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: Wed 11/13/2002 at 00: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:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]