[Cosmo-dev] Timezones and the Cosmo UI

[Bobby Rullo]

Easier said than done, unless you figure out all those offsets for an  
arbitrary period of time on the server, and hand them back to the  
client. I don't think that's sufficient though.

How would you come up with something that encapsulates enough of the  
logic required to get those offsets yet is relatively liteweight?

I really would prefer that, as I do think bandwidth might be an issue  
(not really fair to compare a web client to CalDAV clients, since  
CalDAV clients download something once and store it, and Cosmo UI has  
to fetch it every time it needs it) and also I'm scared of how slow  
JS might be in deciphering a boatload of VTIMEZONES. Maybe  
irrationally scared, haven't tried it yet.

One (over?) simplification could be to just figure out what the DST  
dates are for the current year, and assume those are the dates every  
year. Would work in most cases, and wouldn't be too wrong when it is  
wrong.

Would that be good enough?

bobby

On Oct 18, 2006, at 4:02 PM, Brian Moseley wrote:

> On 10/18/06, Bobby Rullo <br at osafoundation.org> wrote:
>
>> Are you saying that you send down the full VTIMEZONE to the client,
>> but have something around it which simplifies use? that's fine.
>
> no, i'm saying that just as you provide a simplified event api that
> the rpc server stuff translates to and from ical4j, you could provide
> a similar simplified timezone api that makes available offsets and
> whatever else you need. that's probably an easier programming model
> for the ui than dealing with a full VTimeZone.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev