Can calendarserver parse libc zoneinfo files?
Here is a brief description of the problem: "The problem is that timezone updates happen frequently. Therefore timezones were split out of the glibc package so they can be updated separately via volatile.debian.org and point release updates. Every package that ships it's own timezone information needs extra care (which usually means it gets outdated rather quickly). So the goal is to use glibc's timezones from the tzdata package (which e.g. python-dateutil uses) everywhere." I am not sure how best to handle this problem. The best obvious solution would be to configure calendarserver to use this timezone database. But, looking at the code for pycalendar, I really doubt if calendarserver will be able to parse libc zoneinfo files. The only other option is to generate the ics files from the zoneinfo database. Any suggestion on how to handle this problem would be appreciated. Regards, Rahul.
Hi Rahul, --On August 15, 2012 2:15:43 AM +0530 Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
Here is a brief description of the problem:
"The problem is that timezone updates happen frequently. Therefore timezones were split out of the glibc package so they can be updated separately via volatile.debian.org and point release updates. Every package that ships it's own timezone information needs extra care (which usually means it gets outdated rather quickly). So the goal is to use glibc's timezones from the tzdata package (which e.g. python-dateutil uses) everywhere."
I am not sure how best to handle this problem. The best obvious solution would be to configure calendarserver to use this timezone database. But, looking at the code for pycalendar, I really doubt if calendarserver will be able to parse libc zoneinfo files. The only other option is to generate the ics files from the zoneinfo database.
Any suggestion on how to handle this problem would be appreciated.
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. 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. -- Cyrus Daboo
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?
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?
Le Aug 14, 2012 à 2:18 PM, Rahul Amaram <amaramrahul@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
Le Aug 14, 2012 à 2:31 PM, Glyph <glyph@twistedmatrix.com> a écrit :
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 :).
As you probably just saw, I just went ahead and got some information from Cyrus on how we currently do this from the Olson database, and shared it at <http://trac.calendarserver.org/wiki/UpdatingTimezones>. I hope this is sufficient for your purposes. It could probably be less of a multi-step manual process, so feel free to file a trac ticket anyway. As I understand it though, in addition to the tool in question dealing with the Olson format and not tzdata, we also need a bit more information from the Olson database than the zoneinfo database uses, so it really will need to go back to the source material. I don't think it can even be modified to derive the data from the tzdata package. -glyph
On Wednesday 15 August 2012 03:01 AM, Glyph wrote:
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
I looked around for any public servers that provided the timezone service. I couldn't find any such service. Anyways, I think the former option of updating the calendarserver timezone database is the better way to handle this situation. Thanks for providing the instructions in the wiki page. I will look into it sometime soon. Regards, Rahul.
participants (3)
-
Cyrus Daboo
-
Glyph
-
Rahul Amaram