[Cosmo-dev] Timezones and the Cosmo UI
br at osafoundation.org
Wed Oct 18 16:15:03 PDT 2006
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
Would that be good enough?
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
More information about the cosmo-dev