Porting zoneinfo routines to Win32?

[Antoine Leca]

Chris Sells <csells at sellsbrothers.com> asked:
> > >Has anyone ported zic or related zoneinfo routines to Win32?

Eric Ulevik <eau at ozemail.com.au> answered:
> > Not that I know of... but I've considered it. The ideal situation would be
> > to take this database and put it under the Win32 APIs. Unfortunately, this
> > is not simple because the Win32 APIs don't understand that time zone rules
> > vary from year to year.

Guy Harris <guy at netapp.com> added:
> Depends on the API.
<detailled discussion snipped>

Definitively.
But, as you outlined, time zone informations are stored on a very
well defined location on Win32 (in the registry), and it should be
relatively easy to store the correct informations coming from our
database to this location.
Of course, as you explained very clearly, only the last pair of rules
can be registered in Win32.  But I think this would be better than
the present state of art proposed by Microsoft...

I began this porting, because I have the same project as Chris, plus
another: making the database available in iCalendar format (which
was designed to match the datas available in the database): see
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-calsch-ical-08.txt>
if you are interested.

To do this, I try to split zic.c in two parts: one responsible
for the parsing of the text datas, and another, including the main
program, responsible for the production of the results.
This is not so easy, because some parts are very tightly coupled
(but I believe it is doable).
This way, it would be easy to write new programs that used the
parsed datas (in struct * forms) in other formats, including
Win32 registry and iCalendar format).

I intend to continue on this way (unless someone already have
done extensive work in this area, or unless the group explained
to me this is a bad idea).  But I shall appreciate any help in
working on this.  I cannot set up a open mailing list (lack
of rights to do so on my host), but I feel a separate mailing
list would be more appropriate, at least for the beginning, than
this list.


Antoine