Re: [Phpgroupware-developers] datetime class localtime bug (causes a calendar bug)

[Dave Hall]

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>