[CalendarServer-dev] Can calendarserver parse libc zoneinfo files?

Glyph glyph at twistedmatrix.com
Tue Aug 14 14:31:05 PDT 2012


Le Aug 14, 2012 à 2:18 PM, Rahul Amaram <amaramrahul at users.sourceforge.net> a écrit :

> 
> 
> On Tuesday 14 August 2012 11:22 PM, Cyrus Daboo wrote:
>> 
>> We already have tools in place to parse the Olson data (which is itself the source of the OS zoneinfo data) and update the server's internal database. Typically we do that ourselves and include the updated database in our subversion repository. However, it is possible for that to be done independently - but we do not have instructions on that at present.
> Could the tool be shared so that it can be used for dynamically updating the calendarserver timezone database whenever tzdata package gets updated?

This sounds like a reasonable idea.  Can you file a ticket in Trac so that we keep track of it?  And of course feel free to keep pinging us about it :).

>> Also, calendar server supports an implementation of the proposed standard timezone service protocol (<https://datatracker.ietf.org/doc/draft-douglass-timezone-service/>). The goal with that is to allow rapid propagation of timezone data changes between systems. Our server has the ability to be a "primary" or "secondary" server. The former being an "authoratative" source of timezone information (in our case derived directly from Olson data). The later is a server that pulls its data from another timezone service. The goal is to properly standardize this new protocol and work on getting people to deploy servers that anyone can use.
>> 
> Does this mean that I can configure calendarserver for updating its timezone database from another service? How do I configure this?

Yes.  Look at the TimezoneService plist entry (have a look at stdconfig.py for the closest thing to documentation on that option ;-).  You need to set the server as a "secondary" rather than a "primary" (the default), and set TimezoneService.SecondaryService.Host / .URI to another timezone service that implements this draft specification.  We have done interop testing on other Calendar Server instances, DAViCal <http://davical.org>, and Bedework <http://www.jasig.org/bedework>.

-glyph


More information about the calendarserver-dev mailing list