net TZ access

Antoine Leca Antoine.Leca at renault.fr
Wed Oct 1 09:23:53 UTC 1997


Nathan Myers wrote:
> 
> From: Paul Eggert <eggert at twinsun.com>:
> > Other solutions would reduce the IP traffic even further.  For
> > example, the time zone server could notify the clients of changes
> > instead of requiring the clients to poll the server.  This could be
> > done via multicast to cut down on packet transmission even further.
> 
> A "push" policy (with attendant daemons, subcriptions, etc) would be
> a hard sell for something like time zone information that changes so
> infrequently, and has such a low perception of importance among those
> not subscribed to this list.

Um... I beg to differ (a lot).

Here in continental Europe, we have a major difference in the
timezone policy last autumn, which were for some of us the first year
we live with Windows '95.

In case you don't know, Windows '95, when compared with Windows 3.x,
add the benefit of an automated following of DST changes.
But this benefit have been canceled last year; as Windows '95 was
programmed for the ancient rules, it failed two times:
- first at the end of september, when it announced falsely the end
  of summer time;
- and then at the end of october, when it failed to announce the
  end of summer time...
For some people, who are not MS enthouiast, this was interpreted as
a major failure of Windows '95, with the obvious solution that the
better would be to drop the DST control by the OS (or better, to drop
that OS...)

As an evidence, all these peoples which were annoyed don't subscribe
to this list.  And I'm sure that they (as a whole) would benefit of
a "push" protocol in order to keep their computers' clocks right.

IF THIS DON'T COST ANYTHING TO THEM.

(Well, if it is a few cents, I think it will be OK.  But continuous
 polling, or polling every day, for peoples connected to Internet
 via modems and private phone lines, is IMHO inacceptable.)

 
> > If you're stuck with a protocol in which the client must poll the
> > server, then probably the best you can do is have the clients poll
> > once after each reboot or reconnect, and also once a day at a random
> > time.  One packet-exchange per day should be acceptable overhead for
> > almost all applications.

It sounds like a NNTP-like protocol, doesn't it?
Thus, can NNTP be extended to signal a change in TZ information?
(This is just an idea out of my head, I don't know the internals of
 NNTP, so I know nothing about the feasability).

 
Antoine Leca



More information about the tz mailing list