[eGroupWare-core] Re: [eGroupWare-developers] Re: [eGroupWare-core] xmlrpc System.Time method patch...

[Miles L. <mi...@gr...>]

I think even calendar uses the datetime class in the api for some
things.  Other apps should use this or functions called from the common
class, etc.  Somewhere there is an option that may be called
inconsistently, causing all the time differences.  It doesn't matter
much to me which time is used, although GMT is probably a good choice.
Server time may be what is available, however, without a lot of
modification or calculation.  The other problem is that the dates are
stored in SQL in perhaps different time zones based on user pref or not.
I hope they are all using server time at least.  The user pref can be
added for html output, and I would expect that it is.

On Wed, 2005-12-28 at 19:02 +0100, Esben Laursen wrote:
> Carsten Wolff wrote:
> > (stopping cross-post, 56k Modem reminds me, why cross-posting sucks ;))
> 
> Sorry about that, didnt know any one still uses 56K ;-)
> 
> > Hi all,
> > 
> > On Tuesday 27 December 2005 23:32, Esben Laursen wrote:
> > 
> >>some Apps returns time as local other as GMT. Its rather frustrating
> >>that its not consistant.. :-)
> > 
> > 
> > It should definitely be consistant. As it seems, that you already checked some 
> > apps, could you tell us what the status of those apps is regarding 
> > usertime/servertime over xmlrpc (where "usertime" is the time honoring the 
> > user preference for timezone)? Then we should agree on a consitant rule for 
> > XMLRPC timezones. Miles, in an older discussion, your idea was to make the 
> > timezone-preference (alongside other preferences) available to xmlrpc and 
> > always use usertime with xmlrpc. Is this done? Otherwise I still think, 
> > normalizing all times to GMT before sending to XMLRPC is a good idea.
> 
> It has been a while, since I have checked it. I have only tested 
> Calendar and Contacts. Calendar send in local time, where Contacts sends 
> in GMT.
> 
> I do not belive that Contacts honor the user proference, but Im not 
> completly sure, although I believe that calendar does (or use to, havent 
> tested with ver. 1.2)
> 
> > 
> >>Therefore a time standart with the time zone incorporated sound good for
> >>me..
> > 
> > 
> > Sure, it sounds good, but we can not change the format. Remember all the 
> > trouble with two "official" variants of dateTime.iso8601? Adding the timezone 
> > would break clients again (at least if it's made default and just the option 
> > would not be a solution to all clients). No, we should think of a general 
> > solution, that does not depend on stretching the xmlrpc-standard.
> > 
> 
> Yes, I do remember. Thats bad, baaaaad... So I think that all times 
> should be GMT, then we have a fixed point. But how do we check, change 
> or do that?
> 
> 
> Cheers
> 
> Esben
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> eGroupWare-core mailing list
> eGr...@li...
> https://lists.sourceforge.net/lists/listinfo/egroupware-core