Timezone needed?

Stephan Buys list at codefusion.co.za
Wed Jun 30 08:12:41 CEST 2004


Agreed. UTC is the one safe bet that we have. And with the least amount of
"what-ifs". Daylight-saving, etc, etc is controlled through the timezones which
are client-driven.

On Wednesday 30 June 2004 06:54, Joon Radley wrote:
> Hi Bernhard
> 
> > I guess it is not necessary to completey use the XML format 
> > to show the principal question, pseude code should do it.
> > 
> > Recurring event, saved as:
> > 	Subject: Team gathering
> > 	Recurring: Every first monday
> >         Time: 9:30  Timezone: Europe/Berlin
> > 
> > So the client know that this is 8:30 UTC in January and 7:30 
> > UTC in July and will show the appointments there.
> 
> I actualy want to see how you will encapsulate the information into data
> that I can parse.
> 
> In pseude code UTC will work like this
> 
> Recurring event, saved as:
> 	Subject: Team gathering
> 	Recurring: Every first monday
>         Time: 7:30 UTC
>  
> The client will translate from UTC to local time (OS knowing about daylight
> savings time) and display the appointment as 9:30 (Europe/Berlin )in January
> and 9:30 (Europe/Berlin) in July.
> 
> You are looking from the point of view that when daylight savings time kicks
> in the definition of UTC changes. UTC does not change, your time _zone_
> changes and this will reflect when you translate from UTC to local time.
> 
> UTC is always the same for everybody all the time.
> 
> > > > Also please show me how this must be handled if the 
> > appointment is 
> > > > created in another time zone for this example. (E.g The CEO makes 
> > > > the entry while in South Africa (using the CAT as local time), to 
> > > > reoccur in Germany (using CET with and without daylight 
> > savings) on 
> > > > his return )
> > 
> > RFC2445 nicely descripes that floating times can have its 
> > uses, too, but this is outside of my remark. I also believe 
> > that floating times can become a hassle in implementing and 
> > showing the user something useful.
> > 
> > Above I am using a time and date with a  timezone which is 
> > fixed for each recurring event. When creating the event, the 
> > CEO decides in which timezone he thinks. If he makes the 
> > event in Africa/Johannesburg that means this is 7:30 UTC in 
> > January and July leading up to his client showing him 8:30 in 
> > January and 9:30 in July when being in Europe/Berlin.
> > 
> > > Another thing: Since none of the clients support actually 
> > doing this, 
> > > I think it's pretty theoretical.
> > 
> > What does Kontact do currently, if we create such an event?
> > Bernhard
> > 
> 
> So basically you would like to move the resposibility of translation from
> stored date to local time away from the operating system to the mail client.
> 
> Regards
> 
> Joon Radley
> Radley Network Technologies CC
> Cell: +27 (0)83 368 8557
> Fax: +27 (0)12 998 4346
> E-mail: joon at radleys.co.za
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
> 
> 
> 

-- 
Stephan  Buys
Code Fusion cc.
Tel: +27 11 391 1412
Mobile: +27 83 294 1876
Email: s.buys at codefusion.co.za

E-mail Solutions, Kolab Specialists.
http://www.codefusion.co.za




More information about the format mailing list