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