Skip to content

Commit 8cf4cd4

Browse files
levkowetzlevkowetz
committed
Added the utility program used to generate timezone-specific iCalendar information, and the original .ics files generated by the utility program in 2010.
 - Legacy-Id: 6496
1 parent 16ae35a commit 8cf4cd4

File tree

397 files changed

+36485
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

397 files changed

+36485
-0
lines changed

‎vzic/ChangeLog‎

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
2006-03-18 Damon Chaplin <damon@gnome.org>
2+
3+
* Released Vzic 1.3
4+
5+
2006-03-18 Damon Chaplin <damon@gnome.org>
6+
7+
* vzic-output.c (expand_tzname): added special case for America/Nome.
8+
(output_rrule): made hacks a bit more general, to handle Asia/Gaza
9+
which now has a day=4 rule. At some point we should check what newer
10+
versions of Outlook can handle so we can be more accurate.
11+
12+
* vzic-dump.c (dump_time_zone_names): try looking for timezone info
13+
using original and linked name.
14+
15+
* README, *.c: fixed spelling 'compatable' -> 'compatible'.
16+
17+
* vzic.c: patch from Jonathan Guthrie to support a --olson-dir option.
18+
19+
2003-10-25 Damon Chaplin <damon@gnome.org>
20+
21+
* Released Vzic 1.2
22+
23+
2003-10-25 Damon Chaplin <damon@gnome.org>
24+
25+
* vzic-output.c:
26+
* Makefile: moved the PRODUCT_ID and TZID_PREFIX settings to the
27+
Makefile and changed the default so people don't accidentally use
28+
the same IDs as Evolution.
29+
30+
* vzic-parse.c (parse_time): substitute 23:59:59 when we read a time
31+
of 24:00:00. This is a bit of a kludge to avoid problems, since
32+
24:00:00 is not a valid iCalendar time. Since 24:00:00 is only used
33+
for a few timezones in the 1930s it doesn't matter too much.
34+
35+
To write a correct fix we'd need to review all the code that deals
36+
with times to see if it would be affected, e.g. a time of 24:00 on
37+
one day should be considered equal to 0:00 the next day.
38+
39+
We'd also need to adjust the output times to use 0:00 the next day
40+
rather than 24:00. If we need to output recurrence rules that would
41+
be a problem, since 'last saturday at 24:00' can't be easily
42+
converted to another rule that uses 0:00 instead.
43+
44+
2003-10-22 Damon Chaplin <damon@gnome.org>
45+
46+
* Released Vzic 1.1
47+
48+
2003-10-22 Damon Chaplin <damon@gnome.org>
49+
50+
* vzic-parse.c (parse_time): allow a time of 24:00, as used in
51+
the America/Montreal and America/Toronto rules in the 1930s!
52+
I'm not 100% sure the rest of the code will handle this OK, but
53+
it only affects the 'pure' output.
54+
55+
2003-09-01 Damon Chaplin <damon@gnome.org>
56+
57+
* Released Vzic 1.0

‎vzic/Makefile‎

Lines changed: 90 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,90 @@
1+
2+
#
3+
# You will need to set this to the directory that the Olson timezone data
4+
# files are in.
5+
#
6+
OLSON_DIR = /usr/share/olson-icalendar/
7+
8+
9+
# This is used as the PRODID property on the iCalendar files output.
10+
# It identifies the product which created the iCalendar objects.
11+
# So you need to substitute your own organization name and product.
12+
PRODUCT_ID = -//IETF Tools//NONSGML ietf-agenda-ical 1.03//EN
13+
14+
# This is what libical-evolution uses.
15+
#PRODUCT_ID = -//Ximian//NONSGML Evolution Olson-VTIMEZONE Converter//EN
16+
17+
18+
# This is used to create unique IDs for each VTIMEZONE component.
19+
# The prefix is put before each timezone city name. It should start and end
20+
# with a '/'. The first part, i.e. 'myorganization.org' below, should be
21+
# a unique vendor ID, e.g. use a hostname. The part after that can be
22+
# anything you want. We use a date and version number for libical. The %D
23+
# gets expanded to today's date. There is also a vzic-merge.pl which can be
24+
# used to merge changes into a master set of VTIMEZONEs. If a VTIMEZONE has
25+
# changed, it bumps the version number on the end of this prefix. */
26+
TZID_PREFIX = /tools.ietf.org/Olson_%D_1/
27+
#TZID_PREFIX = /
28+
29+
# This is what libical-evolution uses.
30+
#TZID_PREFIX = /softwarestudio.org/Olson_%D_1/
31+
32+
33+
# Set any -I include directories to find the libical header files, and the
34+
# libical library to link with. You only need these if you want to run the
35+
# tests. You may need to change the '#include <ical.h>' line at the top of
36+
# test-vzic.c as well.
37+
LIBICAL_CFLAGS =
38+
LIBICAL_LDADD = -lical-evolution
39+
40+
41+
#
42+
# You shouldn't need to change the rest of the file.
43+
#
44+
45+
GLIB_CFLAGS = `pkg-config --cflags glib-2.0`
46+
GLIB_LDADD = `pkg-config --libs glib-2.0`
47+
48+
CFLAGS = -g -DOLSON_DIR=\"$(OLSON_DIR)\" -DPRODUCT_ID='"$(PRODUCT_ID)"' -DTZID_PREFIX='"$(TZID_PREFIX)"' $(GLIB_CFLAGS) $(LIBICAL_CFLAGS)
49+
50+
OBJECTS = vzic.o vzic-parse.o vzic-dump.o vzic-output.o
51+
52+
all: vzic
53+
54+
vzic: $(OBJECTS)
55+
$(CC) $(OBJECTS) $(GLIB_LDADD) -o vzic
56+
57+
test-vzic: test-vzic.o
58+
$(CC) test-vzic.o $(LIBICAL_LDADD) -o test-vzic
59+
60+
# Dependencies.
61+
$(OBJECTS): vzic.h
62+
vzic.o vzic-parse.o: vzic-parse.h
63+
vzic.o vzic-dump.o: vzic-dump.h
64+
vzic.o vzic-output.o: vzic-output.h
65+
66+
test-parse: vzic
67+
./vzic-dump.pl $(OLSON_DIR)
68+
./vzic --dump --pure
69+
@echo
70+
@echo "#"
71+
@echo "# If either of these diff commands outputs anything there may be a problem."
72+
@echo "#"
73+
diff -ru zoneinfo/ZonesPerl zoneinfo/ZonesVzic
74+
diff -ru zoneinfo/RulesPerl zoneinfo/RulesVzic
75+
76+
test-changes: vzic test-vzic
77+
./test-vzic --dump-changes
78+
./vzic --dump-changes --pure
79+
@echo
80+
@echo "#"
81+
@echo "# If this diff command outputs anything there may be a problem."
82+
@echo "#"
83+
diff -ru zoneinfo/ChangesVzic test-output
84+
85+
clean:
86+
-rm -rf vzic $(OBJECTS) *~ ChangesVzic RulesVzic ZonesVzic RulesPerl ZonesPerl test-vzic test-vzic.o
87+
88+
.PHONY: clean perl-dump test-parse
89+
90+

‎vzic/README‎

Lines changed: 202 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,202 @@
1+
2+
3+
VZIC README
4+
===========
5+
6+
This is 'vzic', a program to convert the Olson timezone database files into
7+
VTIMEZONE files compatible with the iCalendar specification (RFC2445).
8+
9+
(The name is based on the 'zic' program which converts the Olson files into
10+
time zone information files used by several Unix C libraries, including
11+
glibc. See zic(8) and tzfile(5).)
12+
13+
14+
15+
REQUIREMENTS
16+
============
17+
18+
You need the Olson timezone database files, which can be found at:
19+
20+
ftp://elsie.nci.nih.gov/pub/
21+
22+
(Old versions can be found at ftp://munnari.oz.au/pub/oldtz/)
23+
24+
25+
Vzic also uses the GLib library (for hash tables, dynamic arrays, and date
26+
calculations). You need version 2.0 or higher. You can get this from:
27+
28+
http://www.gtk.org
29+
30+
31+
32+
BUILDING
33+
========
34+
35+
Edit the Makefile to set the OLSON_DIR, PRODUCT_ID and TZID_PREFIX variables.
36+
37+
Then run 'make'.
38+
39+
40+
41+
RUNNING
42+
=======
43+
44+
Run 'vzic'.
45+
46+
The output is placed in the zoneinfo subdirectory by default,
47+
but you can use the --output-dir options to set another toplevel output
48+
directory.
49+
50+
By default it outputs VTIMEZONEs that try to be compatible with Outlook
51+
(2000, at least). Outlook can't handle certain iCalendar constructs in
52+
VTIMEZONEs, such as RRULEs using BYMONTHDAY, so it has to adjust the RRULEs
53+
slightly to get Outlook to parse them. Unfortunately this means they are
54+
slightly wrong. If given the --pure option, vzic outputs the exact data,
55+
without worrying about compatability.
56+
57+
NOTE: We don't convert all the Olson files. We skip 'backward', 'etcetera',
58+
'leapseconds', 'pacificnew', 'solar87', 'solar88' and 'solar89', 'factory'
59+
and 'systemv', since these don't really provide any useful timezones.
60+
See vzic.c.
61+
62+
63+
64+
MERGING CHANGES INTO A MASTER SET OF VTIMEZONES
65+
===============================================
66+
67+
The Olson timezone files are updated fairly often, so we need to build new
68+
sets of VTIMEZONE files. Though we have to be careful to ensure that the TZID
69+
of updated timezones is also updated, since it must remain unique.
70+
71+
We use a version number on the end of the TZID prefix (see the TZIDPrefix
72+
variable in vzic-output.c) to ensure this uniqueness.
73+
74+
But we don't want to update the version numbers of VTIMEZONEs which have not
75+
changed. So we use the vzic-merge.pl Perl script. This merges in the new set
76+
of VTIMEZONEs with a 'master' set. It compares each new VTIMEZONE file with
77+
the one in the master set (ignoring changes to the TZID). If the new
78+
VTIMEZONE file is different, it copies it to the master set and sets the
79+
version number to the old VTIMEZONE's version number + 1.
80+
81+
To use vzic-merge.pl you must change the $MASTER_ZONEINFO_DIR and
82+
$NEW_ZONEINFO_DIR variables at the top of the file to point to your 2 sets of
83+
VTIMEZONEs. You then just run the script. (I recommend you keep a backup of
84+
the old master VTIMEZONE files, and use diff to compare the new master set
85+
with the old one, in case anything goes wrong.)
86+
87+
You must merge in changes to the zones.tab file by hand.
88+
89+
Note that some timezones are renamed or removed occasionally, so applications
90+
should be able to cope with this.
91+
92+
93+
94+
COMPATABILITY NOTES
95+
===================
96+
97+
It seems that Microsoft Outlook is very picky about the iCalendar files it
98+
will accept. (I've been testing with Outlook 2000. I hope the other versions
99+
are no worse.) Here's a few problems we've had with the VTIMEZONEs:
100+
101+
o Outlook doesn't like any years before 1600. We were using '1st Jan 0001'
102+
in all VTIMEZONEs to specify the first UTC offset known for the timezone.
103+
(The Olson data does not give a start date for this.)
104+
105+
Now we just skip this first component for most timezones. The UTC offset
106+
can still be found from the TZOFFSETFROM property of the first component.
107+
108+
Though some timezones only specify one UTC offset that applies forever,
109+
so in these cases we output '1st Jan 1970' (Indian/Cocos,
110+
Pacific/Johnston).
111+
112+
o Outlook doesn't like the BYMONTHDAY specifier in RRULEs.
113+
114+
We have changed most of the VTIMEZONEs to use things like 'BYDAY=2SU'
115+
rather than 'BYMONTHDAY=8,9,10,11,12,13,14;BYDAY=SU', though some of
116+
them were impossible to convert correctly so they are not always correct.
117+
118+
o Outlook doesn't like TZOFFSETFROM/TZOFFSETTO properties which include a
119+
seconds component, e.g. 'TZOFFSETFROM:+110628'.
120+
Quite a lot of the Olson timezones include seconds in their UTC offsets,
121+
though no timezones currently have a UTC offset that uses the seconds
122+
value.
123+
124+
We've rounded all UTC offsets to the nearest minute. Since all timezone
125+
offsets currently used have '00' as the seconds offset, this doesn't lose
126+
us much.
127+
128+
o Outlook doesn't like lines being split in certain places, even though
129+
the iCalendar spec says they can be split anywhere.
130+
131+
o Outlook can only handle one RDATE or a pair of RRULEs. So we had to remove
132+
all historical data.
133+
134+
135+
TESTING
136+
=======
137+
138+
Do a 'make test-vic', then run ./test-vic.
139+
140+
The test-vzic program compares our libical code and VTIMEZONE data against
141+
the Unix functions like mktime(). It steps over a period of time (1970-2037)
142+
converting from UTC to a given timezone and back again every 15 minutes.
143+
Any differences are output into the test-output directory.
144+
145+
The output matches for all of the timezones, except in a few places where the
146+
result can't be determined. So I think we can be fairly confident that the
147+
VTIMEZONEs are correct.
148+
149+
Note that you must use the same Olson data in libical that the OS is using
150+
for mktime() etc. For example, I am using RedHat 9 which uses tzdata2002d,
151+
so I converted this to VTIMEZONE files and installed it into the libical
152+
timezone data directory before testing. (You need to use '--pure' when
153+
creating the VTIMEZONE files as well.)
154+
155+
156+
Testing the Parsing Code
157+
------------------------
158+
159+
Run 'make test-parse'.
160+
161+
This runs 'vzic --dump' and 'perl-dump' and compares the output. The diff
162+
commands should not produce any output.
163+
164+
'vzic --dump' dumps all the parsed data out in the original Olson format,
165+
but without comments. The files are written into the ZonesVzic and RulesVzic
166+
subdirectories of the zoneinfo directory.
167+
168+
'make perl-dump' runs the vzic-dump.pl perl script which outputs the files
169+
in the same format as 'vzic --dump' in the ZonesPerl and RulesPerl
170+
subdirectories. The perl script doesn't actually parse the fields; it only
171+
strips comments and massages the fields so we have the same output format.
172+
173+
Currently they both produce exactly the same output so we know the parsing
174+
code is OK.
175+
176+
177+
Testing the VTIMEZONE Files
178+
---------------------------
179+
180+
Run 'make test-changes'.
181+
182+
This runs 'vzic --dump-changes' and 'test-vzic --dump-changes' and compares
183+
the output. The diff command should not produce any output.
184+
185+
Both commands output timezone changes for each zone up to a specific year
186+
(2030) into files for each timezone. It outputs the timezone changes in a
187+
list in this format:
188+
189+
Timezone Name Date and Time of Change in UTC New Offset from UTC
190+
191+
America/Dawson 26 Oct 1986 2:00:00 -0800
192+
193+
Unfortunately there are some differences here, but they all happen before
194+
1970 so it doesn't matter too much. It looks like the libical code has
195+
problems determining things like 'last Sunday of the month' before 1970.
196+
This is because it uses mktime() etc. which can't really handle dates
197+
before 1970.
198+
199+
200+
201+
Damon Chaplin <damon@gnome.org>, 25 Oct 2003.
202+

0 commit comments

Comments
 (0)