Subject: [Tzdist] GSoC project to implement a tzdist client?

From: Martin Burnicki <[email-masked]>
Date: Thu, 23 Oct 2014 16:09:37 +0200

Whenever a TZ data base has to be updated the current procedure to 
deploy the new rules is to update some registry settings under Windows 
accordingly, or update the TZ DB files and compile the binary zone 
file(s) e.g. under Linux.

When a tzdist service becomes available it would be great if clients 
could do this by themselves, i.e. getting updates from the tzdist server 
by using the specified protocol, and providing the underlying OS with 
updated data in the form required by the specific OS.

So my question is:

Is there already an ongoing development of some publicly available 
client software for different OSs, or could this be a good proposal for 
a Google Summer of Code (GSoC) project where some student could work on 
an implementation?

I hope this question is not out of scope for this mailing list.

Martin

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 23 Oct 2014 10:51:11 -0400

Hi Martin,

--On October 23, 2014 at 4:09:37 PM +0200 Martin Burnicki 
<[email-masked]> wrote:

> Whenever a TZ data base has to be updated the current procedure to deploy
> the new rules is to update some registry settings under Windows
> Is there already an ongoing development of some publicly available client
> software for different OSs, or could this be a good proposal for a Google
> Summer of Code (GSoC) project where some student could work on an
> implementation?
>

It has always been my hope that direct updates of zoneinfo files and even 
Windows registry data could be done via tzdist. There are several options 
for this:

1) The OS's use the existing iCalendar-based tzdata to generate the data 
they need locally.

2) The tzdist server offers data in the precise format the OS's need - that 
would require standardizing and registering (media types) for the zoneinfo 
and Windows registry formats.

3) Develop a more generic format for tzdata from which iCalendar, zoneinfo, 
registry formats can be easily derived and allow clients to operate with 
that.

At this point #1 is currently served by the existing proposal. #2 and #3 
will also work with the current protocol once media types have been defined.

-- 
Cyrus Daboo

---

From: Martin Burnicki <[email-masked]>
Date: Thu, 23 Oct 2014 17:15:30 +0200

Hi Cyrus,

Cyrus Daboo wrote:
> It has always been my hope that direct updates of zoneinfo files and
> even Windows registry data could be done via tzdist. There are several
> options for this:
>
> 2) The tzdist server offers data in the precise format the OS's need -
> that would require standardizing and registering (media types) for the
> zoneinfo and Windows registry formats.
>
> 3) Develop a more generic format for tzdata from which iCalendar,
> zoneinfo, registry formats can be easily derived and allow clients to
> operate with that.
>

Hm, as far as I know #1 had to be implemented by the OS maintainers 
first. I've never heard that current versions of Windows, Linux, *BSD, 
Solaris, MacOS or whatever support this, yet, so this will only work 
with future versions of these OSs.

In my opinion solution #2 would not be an appropriate solution anyway. 
Instead a unique protocol format should be preferred, as is discussed here.

As far as as I know there are existing applications which can evaluate 
the original TZ DB format and update the Windows registry, and there is 
the zic compiler which can generate binary time zone files from the 
native TZ DB, and if there's already some existing code which queries TZ 
information from a tzdist server it's just a matter of effort to use 
this as front end to retrieve updates via the unique protocol, and then 
convert it to a format understood by the target OS.

Such tzdist client service could be installed on existing computer and 
OS versions to do this job, and eventually it could be a good GSoC 
project to put these things together for different OSs.

Of course how this has to be implemented is out of scope for this draft, 
but I think this mailing list is the best point to discuss this.

Martin