[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Phpgroupware-developers] datetime class localtime bug (causes a cal
From: |
Dave Hall |
Subject: |
Re: [Phpgroupware-developers] datetime class localtime bug (causes a calendar bug) |
Date: |
Tue, 17 Dec 2002 16:15:30 +1100 |
Chris Weiss <address@hidden> wrote:
> hm. Guess no one caught that I was totaly on the wrong track. I
> finaly figured it
> out and I know what needs fixed, and it's in setupIII.
>
> First, adding the global to the header didn't work because the
> tz_offset actually
> comes from the config table. Turns out setup puts it there.
> Setup blindly assumes
> that the server is in GMT, which i'm guessing in reality most
> servers that serve a
> single location (small to medium size buissness, or our target
> audence) are in local
> time and make good use of the system timezone.
I think you are wrong on the server assuming everyone is gmt :)
what it actaully does it grabs the gmt time value from the
time-a.nist.gov time server via daytime or http. Looks at the system
time and calcualtes the server's offset from there.
>
> Solutions?
> a) get rid of the too smart for its-own-good guess my time zone
> functions and just
> flat out ask in setup for the tz offset
I would actually go one step further, and make it use a proper timezone
location identifier. At the moment the system only allows for full hour
tz offsets. Where as in South Australia it is AEST - GMT +9.5 (or
AEDST GMT + 10.5 in summer). See
http://greenwichmeantime.com/local/australia/index.htm
I think we can ignore summer time for now, that gets too complicated for
the calendar. Especially considering .nz is now GMT +13
> -or-
> b) use some better magic to determine the tz the servers time is
> really set to and
> set datetime->users_localtime corrrectly.
This would be good. I would suggest that there to be the option of
using using either 'system default' or location tz offsets. So a user
can use the 'system default' or selects their tz location ie AU/AEST or
US/PST or whatever and this is value is used. This way it is more
consistent.
I know that some users set the system offset and then their own and so
double to offset. They know who they are ;)
I am sure that we could find a db table that has all the data already in
it. I am looking for one now. I think the follow db would be needed:
tz_id - INT primary key - stored in user prefs and phpgw_config
short_name - VARCHAR(10) - ie AU/AEST, US/PST etc
long_name - VARCHAR(100?) - Australia / Eastern Standard Time, etc
tz_offset - INT - the value ie 10 or -5 etc
tz_summer - INT - the summer time tz offset ie 11 or -4 etc *
summer_start - INT - epoch for start summertime *
summer_end - INT - epoch end for summertime *
Note: * These can wait and probably need more thought. Just me thinking
out loud.
>
> "a" adds a single trivial step to the setup app, and "b" is just
> plain complicated.
>
> If there's agreemenet that this is indeed how it should be fixed
> I'll edit setup and
> make a patch to do "a" just as soon as I find one of them rountuits
>
> until then, and here's the really odd part:
> 1) go into setup and save the Step2 config, you don't have to
> change anything just
> save it.
> 2) before anyone does anything edit the tz_offset field in
> phpgw_config table to
> your tz offset, mine is zero "0".
But then i would need to go and set all my user prefs to use a tz offset
which is a PITA.
>
> for some reason just making the change in the table doesn't do it,
> I have to save
> the config first. Really strange though I'm sure there's a very
> good reason for it.
If skeeter was here i am sure he would know why it was done.
If hope I haven't made things more complicated than they already are. I
personally would be happy with option 'a' for now if it is the only way
to do it. But I would like to look at a combination of 'b' and my
suggestions for the future.
Cheers
Dave
>
> Chris Weiss (address@hidden) wrote*:
> >
> >ok this gets even more interesting:
> >
> >If $this->gmtnow is false the code is looking to see if
> "$GLOBALS['phpgw_info']>['server']['tz_offset']" has been defined,
> except i can't find anywhere where this
> >value might be set. If it somehow is set, $this->gmtnow = the
> server time - this
> >server tz_offet, then the users offset is applied and everything
> is fine.
> >
> >Since the server tz_offest is not set anywhere at all ever, it
> falls back to:
> >
> >$this->gmtnow = time() - ($this->getbestguess() * 3600);
> >
> >which seems harmless, until we look at getbestguess(), which on
> my server returns -
> >6 so that the line does return the correct GMT time, then adds my
> user pref
> >tz_offest, which is 0 since i'm in the same tz as the server, to
> that and now all
> >the sudden i'm not in Central US time anymore!
> >
> >So basicaly the phpgwapi is assuming the servers time is GMT and
> isn't giving any
> >clear option to tell it otherwise. I added
> "$GLOBALS['phpgw_info']['server']>['tz_offset'] = 0;" to my
> header.inc.php. I won't know if that does the trick till
> >later tonight, but it should work.
> >
> >
> >
>
>
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>
dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>