[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: |
Tue, 18 Mar 2003 16:17:35 -0500 |
=================== 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
- [Phpgroupware-tracker] [Bug #1672] Timestamps & Database issues,
nobody <=