[Cosmo-dev] Timezones and the Cosmo UI

[Mikeal Rogers]

> The presumably go away from their page at least once a day. And you  
> can't cache for the reasons I mentioned in the wiki page, that  
> there is no key to cache on, that everyone has their own  
> implementation of timezones, and we will have to accept them. We  
> could as a compromise assume that all TZ's with the same ID are the  
> same Timezone, which would probably be ok just about all the time.


> So let me elaborate on the strawman proposal I put forth in the  
> last email: We create a TZ structure which just has the observances  
> (like DST) for the current year, and assume that that's always the  
> change over dates. Note: this is just for display purposes! The  
> full complete insanely-detailed Olson timezones will still be  
> stored with the event. Viewing events in the year you are in will  
> always be correct, and viewing events in other users will be  
> usually correct. This to me seems like a reasonable compromise,  
> especially as the only thing that is really being compromised is  
> placement on the canvas, and data integrity is not compromised.

We don't have to store them in the exact timezone we got them in,  
nothing in the CalDAV spec says we should/have to do that. In fact  
Oracle's server converts all timezones to UTC and stores them that way.

I don't think we should be worrying about any client specific  
timezone information, if the TZNAME matches an olson db name then  
store it in that. If not convert it to UTC or convert it to the olson  
timezone we think it should be. If iCal or any other client wants to  
hand us crazy vtimezones that don't match olson db they can just get  
the data back in UTC, if they can't handle that then they aren't spec  
compliant and they won't interop with us or with Oracle's calendar  
server.

-Mikeal