Timezone data is fairly dynamic. It makes sense to have some form of
network service to update timezone data. Does anyone know if there
have been any proposals about a standardized timezone update protocol,
or reasons why there should not be one? Since NTP is well established,
maybe it could be expanded to include timezone data?

Joe writes:
> Timezone data is fairly dynamic. It makes sense to have some form of
> network service to update timezone data.

Maybe, but is it really that dynamic?

> Since NTP is well established, maybe it could be expanded to include
> timezone data?

I'd rather not.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

In article <4a6db4e9-0d7e-41e4-9c4b-2715ee08c090@f10g2000vbf.googlegroups.com>,
Joe  <joseph.krahn@gmail.com> wrote:
>Timezone data is fairly dynamic.

How often does it change in your locale?

>It makes sense to have some form of network service to update
>timezone data.

Whenever you're notified that your locale is changing you can check
here to see if its been incorporated yet
http://www.twinsun.com/tz/tz-link.htm

-- 
					-- Rod --
rodd(at)polylogics(dot)com

Joe wrote:
> Timezone data is fairly dynamic. It makes sense to have
>  some form of network service to update timezone data.
> Does anyone know if there have been any proposals about
>  a standardized timezone update protocol, or reasons
>  why there should not be one? Since NTP is well established,
>  maybe it could be expanded to include timezone data?

What kind of Time Zone Data?

 Data that reflects what time zone the NTP server thinks it is in?


 FYI,
  The Daytime Protocol (RFC-867) provides DST info
   If you were to query a NIST server,
    they provide that as well as NTP
     e.g. time-c.timefreq.bldrdoc.gov
      <http://tf.nist.gov/timefreq/service/its.htm>

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

Joe wrote:
> Timezone data is fairly dynamic. It makes sense to have some form of
> network service to update timezone data. Does anyone know if there
> have been any proposals about a standardized timezone update protocol,
> or reasons why there should not be one? Since NTP is well established,
> maybe it could be expanded to include timezone data?

I don't think it's practical!  The legislatures of the various states 
can and do fiddle with it every year such that Arizona does not 
necessarily follow the same schedule as as South Dakota. The rules may 
not even be consistent from year to year.  It helps the legislatures 
concerned to appear as if they are actually doing something useful.

NTP does not concern itself with time zones or "Daylight Time".  It's 
UTC all the way.  What your computer displays as the time depends on how 
you have it configured.  With, potentially, fifty or more different sets 
of rules for daylight time, I think it's going to be the responsibility 
of the System Administrator to "get it right" for the systems he is 
responsible for.

Joe wrote:
> Timezone data is fairly dynamic. It makes sense to have some form of
> network service to update timezone data. Does anyone know if there
> have been any proposals about a standardized timezone update protocol,
> or reasons why there should not be one? Since NTP is well established,
> maybe it could be expanded to include timezone data?

I recognise the need for resolving this problem.

What I know most about is the world of telecoms operators. Contrary to the advice most of us (chimeheads who hang out here) would give them, there are a lot of network operators who observe local time at lower layers than the presentation layer.

This can include things like:

- call detail records: local time is needed to apply the right tariffs where they depend on time-of-day. I would argue that the CDRs emitted by the network elements should use UTC timestamps, where the time is localised only by the rating system. However, many network operators have the network elements observe local time, causing all sorts of grief in respect of transitions to and from daylight savings time.

- logfiles: similar point. Correlation of events across multiple network elements is "problematic", particularly when they've been timestamped in local time, particularly if the network spans multiple time zones.

So the challenge is to keep tens of thousands of network elements (routers, ATM switches, telephone exchanges etc) aware of when to switch to/from DST during their lifetime of multiple years. Wouldn't it be great if we could do this without manual interventions, or scripts, or even cron jobs?

If local time were used only on equipment that has a presentation layer (OSS and BSS), then this would reduce the size of the problem by at least one if not two orders of magnitude.

(The above does not address the point as to whether or not NTP should be used to distribute time zone information though).

Cheers, Jan

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> Joe wrote:
>> Timezone data is fairly dynamic. It makes sense to have some form of
>> network service to update timezone data. Does anyone know if there
>> have been any proposals about a standardized timezone update protocol,
>> or reasons why there should not be one? Since NTP is well established,
>> maybe it could be expanded to include timezone data?
>
> I don't think it's practical!  The legislatures of the various states 
> can and do fiddle with it every year such that Arizona does not 
> necessarily follow the same schedule as as South Dakota. The rules may 
> not even be consistent from year to year.  It helps the legislatures 
> concerned to appear as if they are actually doing something useful.

Now you are just iterating the reasons why it would be useful to
distribute this info via some network.  The question being asked is
if it could be useful to use an NTP server to distribute it.  An
alternative could be do use some HTTP server, a new dedicated protcol,
or whatever method you could think of.

The advantage of extending NTP could be that you only need to configure
one server to know both time and zone info.

And Yes, OFCOURSE you cannot use this to determine in what zone you
are.  But once you know you are in Arizona or South Dakota, you can
use the info to calculate your timezone offset (depending on date).

Joe wrote:
> Timezone data is fairly dynamic. It makes sense to have some form of
> network service to update timezone data. Does anyone know if there
> have been any proposals about a standardized timezone update protocol,
> or reasons why there should not be one? Since NTP is well established,
> maybe it could be expanded to include timezone data?

There is no need for new protocols.  The Olson timezone files define a 
presentation layer format and session layer can be achieved using ftp 
list commands, for the current repository, or you could use it on HTTP, 
with If-Modified-Since, or other cache refresh options.

Rob wrote:
> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> Joe wrote:
>>> Timezone data is fairly dynamic. It makes sense to have some form of
>>> network service to update timezone data. Does anyone know if there
>>> have been any proposals about a standardized timezone update protocol,
>>> or reasons why there should not be one? Since NTP is well established,
>>> maybe it could be expanded to include timezone data?
>> I don't think it's practical!  The legislatures of the various states 
>> can and do fiddle with it every year such that Arizona does not 
>> necessarily follow the same schedule as as South Dakota. The rules may 
>> not even be consistent from year to year.  It helps the legislatures 
>> concerned to appear as if they are actually doing something useful.
> 
> Now you are just iterating the reasons why it would be useful to
> distribute this info via some network.  The question being asked is
> if it could be useful to use an NTP server to distribute it.  An
> alternative could be do use some HTTP server, a new dedicated protcol,
> or whatever method you could think of.
> 
> The advantage of extending NTP could be that you only need to configure
> one server to know both time and zone info.
> 
> And Yes, OFCOURSE you cannot use this to determine in what zone you
> are.  But once you know you are in Arizona or South Dakota, you can
> use the info to calculate your timezone offset (depending on date).

I believe that the O/S vendors supply a file with timezone data.  If you 
have support, you can even get updates from the vendor.  Since I can't 
afford support (I'm retired and a hobbyist) I have to do it by hand.

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> I believe that the O/S vendors supply a file with timezone data.  If you 
> have support, you can even get updates from the vendor.  Since I can't 
> afford support (I'm retired and a hobbyist) I have to do it by hand.

As Jan Ceuleers also pointed out, the problem is not at all limited
to operating systems.  Any device that obtains time using NTP and wants
to display it in local time needs the info.
This could just as well be a digital clock.

Jan Ceuleers wrote:

> So the challenge is to keep tens of thousands of network elements
> (routers, ATM switches, telephone exchanges etc) aware of when to
> switch to/from DST during their lifetime of multiple years. Wouldn't
> it be great if we could do this without manual interventions, or
> scripts, or even cron jobs?
> 
> If local time were used only on equipment that has a presentation
> layer (OSS and BSS), then this would reduce the size of the problem
> by at least one if not two orders of magnitude.
> 
> (The above does not address the point as to whether or not NTP should
> be used to distribute time zone information though).
> 

I don't think it would make any sense to put this into ntp.

Making all this telco equipment understand a new ntp protocol
extension won't be easier than implementing Olsen's TZ stuff or 
switching to UTC

N

Richard B. Gilbert wrote:

> I believe that the O/S vendors supply a file with timezone data.  If you

Not in general true. Not all Unix system use the Olson package, e.g. SCO 
OpenServer doesn't.  Microsoft store it the the registry, so need to 
provide incremental updates.  Microsoft cannot provide complex future rules.

Even with Olson, there is a file per timezone in the running system.

> have support, you can even get updates from the vendor.  Since I can't 
> afford support (I'm retired and a hobbyist) I have to do it by hand.

Rob wrote:
> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> Joe wrote:
>>> Timezone data is fairly dynamic. It makes sense to have some form of
>>> network service to update timezone data. Does anyone know if there
>>> have been any proposals about a standardized timezone update protocol,
>>> or reasons why there should not be one? Since NTP is well established,
>>> maybe it could be expanded to include timezone data?
>> I don't think it's practical!  The legislatures of the various states 
>> can and do fiddle with it every year such that Arizona does not 
>> necessarily follow the same schedule as as South Dakota. The rules may 
>> not even be consistent from year to year.  It helps the legislatures 
>> concerned to appear as if they are actually doing something useful.
> 
> Now you are just iterating the reasons why it would be useful to
> distribute this info via some network.  The question being asked is
> if it could be useful to use an NTP server to distribute it.  An
> alternative could be do use some HTTP server, a new dedicated protcol,
> or whatever method you could think of.
> 
> The advantage of extending NTP could be that you only need to configure
> one server to know both time and zone info.
> 
> And Yes, OFCOURSE you cannot use this to determine in what zone you
> are.  But once you know you are in Arizona or South Dakota, you can
> use the info to calculate your timezone offset (depending on date).

You don't need to extend NTP to do this.  Just put the file with the 
timezone data on an FTP server and tell us where it is.  Maybe a few 
dozen servers would be better.  I think there is even a "standard" way 
of expressing when ST/DST changes occurred for every year back to 1970 
and a file with the data.

Unfortunately it has disappeared into the sludge at the bottom of my mind!

Nero Imhard <nim@pipe.nl> wrote:
> Making all this telco equipment understand a new ntp protocol
> extension won't be easier than implementing Olsen's TZ stuff or 
> switching to UTC

Is there some distributed server system available where those Olsen
TZ files could be downloaded?
It would of course be no problem to make such data available on
existing HTTP servers like Google's or similar, but has this
actually been done?

David Woolley <david@ex.djwhome.demon.co.uk.invalid> wrote:
> Microsoft store it the the registry, so need to 
> provide incremental updates.  Microsoft cannot provide complex future rules.

This was true in the past, but it has been fixed.

Rob wrote:
> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> I believe that the O/S vendors supply a file with timezone data.  If you 
>> have support, you can even get updates from the vendor.  Since I can't 
>> afford support (I'm retired and a hobbyist) I have to do it by hand.
> 
> As Jan Ceuleers also pointed out, the problem is not at all limited
> to operating systems.  Any device that obtains time using NTP and wants
> to display it in local time needs the info.
> This could just as well be a digital clock.

I have a couple of "radio controlled" digital clocks and a wrist watch 
that do it automagically.  The VLF broadcast from WWVB provides the 
necessary info.

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> Rob wrote:
>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>> I believe that the O/S vendors supply a file with timezone data.  If you 
>>> have support, you can even get updates from the vendor.  Since I can't 
>>> afford support (I'm retired and a hobbyist) I have to do it by hand.
>> 
>> As Jan Ceuleers also pointed out, the problem is not at all limited
>> to operating systems.  Any device that obtains time using NTP and wants
>> to display it in local time needs the info.
>> This could just as well be a digital clock.
>
> I have a couple of "radio controlled" digital clocks and a wrist watch 
> that do it automagically.  The VLF broadcast from WWVB provides the 
> necessary info.

That cannot be true.  It may work for your location, but I'm sure it
does not cover the general case under discussion.

Rob wrote:
> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> Rob wrote:
>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>> I believe that the O/S vendors supply a file with timezone data.  If you 
>>>> have support, you can even get updates from the vendor.  Since I can't 
>>>> afford support (I'm retired and a hobbyist) I have to do it by hand.
>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>> to operating systems.  Any device that obtains time using NTP and wants
>>> to display it in local time needs the info.
>>> This could just as well be a digital clock.
>> I have a couple of "radio controlled" digital clocks and a wrist watch 
>> that do it automagically.  The VLF broadcast from WWVB provides the 
>> necessary info.
> 
> That cannot be true.  It may work for your location, but I'm sure it
> does not cover the general case under discussion.

How can it not be true?  The time broadcast encodes both the time 
(standard time) and whether or not DST is in effect.  Of course it 
doesn't work for those jurisdictions that have chosen to go there own 
way as far as DST is concerned.

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> Rob wrote:
>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>> Rob wrote:
>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>> I believe that the O/S vendors supply a file with timezone data.  If you 
>>>>> have support, you can even get updates from the vendor.  Since I can't 
>>>>> afford support (I'm retired and a hobbyist) I have to do it by hand.
>>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>>> to operating systems.  Any device that obtains time using NTP and wants
>>>> to display it in local time needs the info.
>>>> This could just as well be a digital clock.
>>> I have a couple of "radio controlled" digital clocks and a wrist watch 
>>> that do it automagically.  The VLF broadcast from WWVB provides the 
>>> necessary info.
>> 
>> That cannot be true.  It may work for your location, but I'm sure it
>> does not cover the general case under discussion.
>
> How can it not be true?  The time broadcast encodes both the time 
> (standard time) and whether or not DST is in effect.  Of course it 
> doesn't work for those jurisdictions that have chosen to go there own 
> way as far as DST is concerned.

There you go.  It works for you, but it does not work in the general case.

Richard B. Gilbert writes:
> I believe that the O/S vendors supply a file with timezone data.  If you
> have support, you can even get updates from the vendor.  Since I can't
> afford support (I'm retired and a hobbyist) I have to do it by hand.

Most Linux distributions provide this support for free (Debian certainly
does).  I would be surprised if the BSD distributions don't do so as well.

IMHO a standardized, automated and decentralized way of distributing
changes to timezone files might be useful, though.  It just should not be
part of NTP.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

Richard B. Gilbert wrote:

> How can it not be true?  The time broadcast encodes both the time 
> (standard time) and whether or not DST is in effect.  Of course it 

WWV may encode UTC, but European VLF transmitters transmit wall clock time.

> doesn't work for those jurisdictions that have chosen to go there own 
> way as far as DST is concerned.

Richard B. Gilbert wrote:

> You don't need to extend NTP to do this.  Just put the file with the 
> timezone data on an FTP server and tell us where it is.  Maybe a few 

Already done.


> dozen servers would be better.  I think there is even a "standard" way 
> of expressing when ST/DST changes occurred for every year back to 1970 
> and a file with the data.

Already done, except that it can go back much further than 1970.  There 
are some rules for pre-railway time.

>

Jan writes:
> If local time were used only on equipment that has a presentation layer
> (OSS and BSS), then this would reduce the size of the problem by at least
> one if not two orders of magnitude.

Better to use UTC everywhere and convert to local time only for
presentation.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

David Woolley <david@ex.djwhome.demon.co.uk.invalid> wrote:
> Richard B. Gilbert wrote:
>
>> You don't need to extend NTP to do this.  Just put the file with the 
>> timezone data on an FTP server and tell us where it is.  Maybe a few 
>
> Already done.

Is that FTP server robust enough to allow for e.g. all installations
of a popular operating system to download it automatically from there?

I would think that a more distributed approach is better.

Rob writes:
> I would think that a more distributed approach is better.

Put the file at a standard location on a known set of servers (maybe a
subset of the pool servers?).  Provide the md5sum at the same location so
that software can know when there has been a change.  Seems like the
traffic would be minimal.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

Rob wrote:

> 
> Is that FTP server robust enough to allow for e.g. all installations
> of a popular operating system to download it automatically from there?

Probably not, especially if the designers were lazy and didn't randomise 
the polling.
> 
> I would think that a more distributed approach is better.

For Red Hat and CentOS, it's called yum.

John Hasler <john@dhh.gt.org> wrote:
> IMHO a standardized, automated and decentralized way of distributing
> changes to timezone files might be useful, though.  It just should
> not be part of NTP.

I'm not sure it is as automated and decentralized as you might want,
but there is a mechanism in place to update the "pci.ids" file mapping
all the vendor, product, subvendor subproduct IDs in PCI cards to
human readable text.

http://pciids.sourceforge.net/

which is I believe what the "update-pciids" command under Linux (and
perhaps other OSes) will query when run.

rick jones
-- 
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision.  - Joubert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Rob wrote:
> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> Rob wrote:
>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>> Rob wrote:
>>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>>> I believe that the O/S vendors supply a file with timezone data.  If you 
>>>>>> have support, you can even get updates from the vendor.  Since I can't 
>>>>>> afford support (I'm retired and a hobbyist) I have to do it by hand.
>>>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>>>> to operating systems.  Any device that obtains time using NTP and wants
>>>>> to display it in local time needs the info.
>>>>> This could just as well be a digital clock.
>>>> I have a couple of "radio controlled" digital clocks and a wrist watch 
>>>> that do it automagically.  The VLF broadcast from WWVB provides the 
>>>> necessary info.
>>> That cannot be true.  It may work for your location, but I'm sure it
>>> does not cover the general case under discussion.
>> How can it not be true?  The time broadcast encodes both the time 
>> (standard time) and whether or not DST is in effect.  Of course it 
>> doesn't work for those jurisdictions that have chosen to go there own 
>> way as far as DST is concerned.
> 
> There you go.  It works for you, but it does not work in the general case.

I think it works for most people and places.  Most of the US switches 
to/from DST on the same day.  I don't know about the rest of the western 
  hemisphere but since I seldom leave the continental U.S. it doesn't 
really affect me very much.

David Woolley wrote:
> Richard B. Gilbert wrote:
> 
>> You don't need to extend NTP to do this.  Just put the file with the 
>> timezone data on an FTP server and tell us where it is.  Maybe a few 
> 
> Already done.

Please tell me where to get it.

Once upon a time, Richard B. Gilbert <rgilbert88@comcast.net> said:
>I think it works for most people and places.  Most of the US switches 
>to/from DST on the same day.

By law, all of the US has to switch DST on the same day at the same
local time.  IIRC now, states have to switch or not switch state-wide as
well (even states in more than one time zone).

-- 
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Richard B. Gilbert wrote:
> David Woolley wrote:
>> Richard B. Gilbert wrote:
>>> You don't need to extend NTP to do this.
>>> Just put the file with the timezone data on an FTP
>>>  server and tell us where it is.  Maybe a few
>>
>> Already done.
>
> Please tell me where to get it.

<ftp://elsie.nci.nih.gov/pub/>

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

Chris Adams wrote:
> Richard B. Gilbert said:
>> I think it works for most people and places.
>>   Most of the US switches to/from DST on the same day.
>
> By law, all of the US has to switch DST on the same day
>  at the same local time.  IIRC now, states have to switch
>  or not switch state-wide as well (even states in more
>  than one time zone).

<Sarcasm>
 Yea States never ignore federal laws,
  and do as they wish instead.
</Sarcasm>
  (Not to mention people, and laws in general.)

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

Null writes:
> Yea States never ignore federal laws, and do as they wish instead.

They are free to ignore this law.  They just lose all their Federal
subsidies if they do.  Which means, of course, that they never ignore it.

However, almost every other country in the world has "DST" arrangements at
least as loony as those in the US, and some change the starting and/or
ending dates with as little as a few weeks notice.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

Joe <joseph.krahn@gmail.com> writes:

>Timezone data is fairly dynamic. It makes sense to have some form of
>network service to update timezone data. Does anyone know if there
>have been any proposals about a standardized timezone update protocol,
>or reasons why there should not be one? Since NTP is well established,
>maybe it could be expanded to include timezone data?

No ntp is for distributing UTC. That is all it should be for. 
There are something like 1000 timezones around the world. Why would youburden ntp
with distributing all that junk increasing the data packets by that amount. 
If you want time zone data get the file tzdata.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>Rob wrote:
>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>> Rob wrote:
>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>> I believe that the O/S vendors supply a file with timezone data.  If you 
>>>>> have support, you can even get updates from the vendor.  Since I can't 
>>>>> afford support (I'm retired and a hobbyist) I have to do it by hand.
>>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>>> to operating systems.  Any device that obtains time using NTP and wants
>>>> to display it in local time needs the info.
>>>> This could just as well be a digital clock.
>>> I have a couple of "radio controlled" digital clocks and a wrist watch 
>>> that do it automagically.  The VLF broadcast from WWVB provides the 
>>> necessary info.
>> 
>> That cannot be true.  It may work for your location, but I'm sure it
>> does not cover the general case under discussion.

>How can it not be true?  The time broadcast encodes both the time 
>(standard time) and whether or not DST is in effect.  Of course it 
>doesn't work for those jurisdictions that have chosen to go there own 
>way as far as DST is concerned.

But there are at least 10 different timezone/DST rules for the USA. How does WWV broadcast
them all?

John Hasler wrote:
> Rob writes:
>> I would think that a more distributed approach is better.
> 
> Put the file at a standard location on a known set of servers (maybe a
> subset of the pool servers?).  Provide the md5sum at the same location so
> that software can know when there has been a change.  Seems like the
> traffic would be minimal.

That's overcomplicating it.  The file modification date is plenty good 
enough.  With HTTP you would also have the choice of using 
If-Modified-Since requests or another, tag based, method for conditional 
downloading.

Richard B. Gilbert wrote:
> Rob wrote:
>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>> Rob wrote:
>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>> I believe that the O/S vendors supply a file with timezone data. 
>>>>> If you have support, you can even get updates from the vendor. 
>>>>> Since I can't afford support (I'm retired and a hobbyist) I have
>>>>> to do it by hand. 
>>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>>> to operating systems.  Any device that obtains time using NTP and
>>>> wants to display it in local time needs the info.
>>>> This could just as well be a digital clock.
>>> I have a couple of "radio controlled" digital clocks and a wrist
>>> watch that do it automagically.  The VLF broadcast from WWVB
>>> provides the necessary info.
>> 
>> That cannot be true.  It may work for your location, but I'm sure it
>> does not cover the general case under discussion.
> 
> How can it not be true?  The time broadcast encodes both the time
> (standard time) and whether or not DST is in effect.  Of course it
> doesn't work for those jurisdictions that have chosen to go there own
> way as far as DST is concerned.

Only for one country out of hundreds.

David

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> There you go.  It works for you, but it does not work in the general case.
>
> I think it works for most people and places.  Most of the US switches 
> to/from DST on the same day.  I don't know about the rest of the western 
>   hemisphere but since I seldom leave the continental U.S. it doesn't 
> really affect me very much.

You rightly mention that the VLF time transmitters transmit a timezone
indicator.  However, there is no such indicator in NTP, so a clock running
off NTP instead of a time transmitter does not have that info.
It needs another way to get actual timezone data.

Someone is asking for a distribution mechanism for uptodate timezone data.
It could be part of NTP, it could be another protocol.
That is the topic under discussion.
Your remark that it does not affect you is not very valuable.
The date at which DST starts or ends is not the same all over the world
and it sometimes changes.  So when you don't have a way to obtain the
actual DST yes/no status (as you have when you receive a time transmitter)
you really need the uptodate timezone data.   NTP cannot be extended to
transmit only the DST bit as it is different for different countries and
NTP does not notice country borders.
(VLF time transmitters really don't do so either, so clocks synchronized
to them also need manual configuration and/or overrides)

Unruh <unruh-spam@physics.ubc.ca> wrote:
> Joe <joseph.krahn@gmail.com> writes:
>
>>Timezone data is fairly dynamic. It makes sense to have some form of
>>network service to update timezone data. Does anyone know if there
>>have been any proposals about a standardized timezone update protocol,
>>or reasons why there should not be one? Since NTP is well established,
>>maybe it could be expanded to include timezone data?
>
> No ntp is for distributing UTC. That is all it should be for. 
> There are something like 1000 timezones around the world. Why would youburden ntp
> with distributing all that junk increasing the data packets by that amount. 

Nobody has started to discuss implementation details so there is no
reason to assume that the timezone info would be added to all normal data
packets and/or that 1000 zones would have to be sent.

Unruh wrote:
> Joe <joseph.krahn@gmail.com> writes:
> 
> 
>>Timezone data is fairly dynamic. It makes sense to have some form of
>>network service to update timezone data. Does anyone know if there
>>have been any proposals about a standardized timezone update protocol,
>>or reasons why there should not be one? Since NTP is well established,
>>maybe it could be expanded to include timezone data?
> 
> 
> No ntp is for distributing UTC. That is all it should be for. 
> There are something like 1000 timezones around the world. Why would youburden ntp
> with distributing all that junk increasing the data packets by that amount. 
> If you want time zone data get the file tzdata.
> 
Timezone stuff is "Localisation" and handled forex by libc and/or
other programming frameworks.

And the package manager for "managed" linux distributions ( same for the bsds )
usually present timely updates.

uwe

Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
> Timezone stuff is "Localisation" and handled forex by libc and/or
> other programming frameworks.
>
> And the package manager for "managed" linux distributions ( same for the bsds )
> usually present timely updates.

So your standpoint is that every system builder who wants to do
such localization should be on their own, providing their own update
mechanism, and there should not be a universal update mechanism for
timezone updates that is neutral to operating system?

Rob wrote:
[]
> So your standpoint is that every system builder who wants to do
> such localization should be on their own, providing their own update
> mechanism, and there should not be a universal update mechanism for
> timezone updates that is neutral to operating system?

Initially, using something like NTP to distribute the information sounds 
to have its good points, and some drawbacks.  How much information would 
be involved - how many extra bytes per day would be needed?  How often 
would the data be sent?

Having said that, I do feel that it's an OS issue, and not an NTP issue, 
and if the data is readily available in the correct format, why not just 
retrieve it with FTP or HTTP?  Bu then, how does one ensure that the 
distribution workload is distributed amongst many servers, rather than 
having all the world's PCs querying one server?  Make every NTP server 
optionally an HTTP server on port 123?

Just some random thoughts...

Cheers,
David 

David J Taylor <david-taylor@blueyonder.not-this-part.nor-this.co.uk.invalid> wrote:
> Rob wrote:
> []
>> So your standpoint is that every system builder who wants to do
>> such localization should be on their own, providing their own update
>> mechanism, and there should not be a universal update mechanism for
>> timezone updates that is neutral to operating system?
>
> Initially, using something like NTP to distribute the information sounds 
> to have its good points, and some drawbacks.  How much information would 
> be involved - how many extra bytes per day would be needed?  How often 
> would the data be sent?

A compiled timezone info file is about 2-3 KB in size.
However, it might be that it is not the best option to send it in compiled
form, because this is dependent on issues like wordlength and byteorder.
A similar format but sent as XML could be better.  But it would of course
be several times bigger.

How often it needs to be sent is difficult to say.  Some countries change
those things, others don't.  You may need to send it to newly installed
systems or to devices that don't keep it in permanent storage.

> Having said that, I do feel that it's an OS issue, and not an NTP issue, 
> and if the data is readily available in the correct format, why not just 
> retrieve it with FTP or HTTP?  Bu then, how does one ensure that the 
> distribution workload is distributed amongst many servers, rather than 
> having all the world's PCs querying one server?  Make every NTP server 
> optionally an HTTP server on port 123?

It may well be the best option to use one of the available distributed
HTTP servers (like Google, Akamaitech and others offer) to host a directory
with the timezone files.
Just a fetch of a wellknown URL (like http://zoneinfo.ntp.org/zonename)
would be enough.  The fetch can be done with if-modified-since and the
timestamp of the version you already have.  This can be done e.g. once
a day.
Then no changes to NTP are required and the servers sending the data
are already setup to do such things efficiently.

Of course, it could also be implemented as a new request in NTP.  But that
would mean that servers that support it need to have a cache of the
uptodate zone info files.  Which they presumably update by getting them
from other servers in a tree with the authority at the top.

Bill Unruh writes:
> But there are at least 10 different timezone/DST rules for the USA. How
> does [WWVB] broadcast them all?

They merely provide an indications as to the current DST status.  The
entire US goes on and off DST at the same time.  Here is the format:
<http://en.wikipedia.org/wiki/WWVB#Modulation_Format>
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

Unruh wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
>> Rob wrote:
>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>> Rob wrote:
>>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>>> I believe that the O/S vendors supply a file with timezone data.  If you 
>>>>>> have support, you can even get updates from the vendor.  Since I can't 
>>>>>> afford support (I'm retired and a hobbyist) I have to do it by hand.
>>>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>>>> to operating systems.  Any device that obtains time using NTP and wants
>>>>> to display it in local time needs the info.
>>>>> This could just as well be a digital clock.
>>>> I have a couple of "radio controlled" digital clocks and a wrist watch 
>>>> that do it automagically.  The VLF broadcast from WWVB provides the 
>>>> necessary info.
>>> That cannot be true.  It may work for your location, but I'm sure it
>>> does not cover the general case under discussion.
> 
>> How can it not be true?  The time broadcast encodes both the time 
>> (standard time) and whether or not DST is in effect.  Of course it 
>> doesn't work for those jurisdictions that have chosen to go there own 
>> way as far as DST is concerned.
> 
> But there are at least 10 different timezone/DST rules for the USA. How does WWV broadcast
> them all?

Sorry, but I believe that only four time zones are sufficient to cover 
the continental U.S.  If you include Alaska and Hawaii you need two 
more.  Where did the other four come from?  Of course any jurisdiction 
CAN make its own rules for DST but most do not.

David J Taylor wrote:
> Richard B. Gilbert wrote:
>> Rob wrote:
>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>> Rob wrote:
>>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>>> I believe that the O/S vendors supply a file with timezone data. 
>>>>>> If you have support, you can even get updates from the vendor. 
>>>>>> Since I can't afford support (I'm retired and a hobbyist) I have
>>>>>> to do it by hand. 
>>>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>>>> to operating systems.  Any device that obtains time using NTP and
>>>>> wants to display it in local time needs the info.
>>>>> This could just as well be a digital clock.
>>>> I have a couple of "radio controlled" digital clocks and a wrist
>>>> watch that do it automagically.  The VLF broadcast from WWVB
>>>> provides the necessary info.
>>>
>>> That cannot be true.  It may work for your location, but I'm sure it
>>> does not cover the general case under discussion.
>>
>> How can it not be true?  The time broadcast encodes both the time
>> (standard time) and whether or not DST is in effect.  Of course it
>> doesn't work for those jurisdictions that have chosen to go there own
>> way as far as DST is concerned.
> 
> Only for one country out of hundreds.
> 
> David

Only ONE is important to me these days!

Richard B. Gilbert wrote:
> David J Taylor wrote:
[]
>> Only for one country out of hundreds.
>>
>> David
>
> Only ONE is important to me these days!

I cannot take that view, Richard, as I write software which is used in 
dozens of countries and time zones.  My software works purely in UTC, and 
allows the OS to handle time presentation, with or without time-zone 
information.  A single country solution would be completely unacceptable.

David 

Rob <nomail@example.com> writes:

>Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
>> Timezone stuff is "Localisation" and handled forex by libc and/or
>> other programming frameworks.
>>
>> And the package manager for "managed" linux distributions ( same for the bsds )
>> usually present timely updates.

>So your standpoint is that every system builder who wants to do
>such localization should be on their own, providing their own update
>mechanism, and there should not be a universal update mechanism for
>timezone updates that is neutral to operating system?

There already is such a mechanism. It is called the tzdata file. Download it once
a month and install it via a cron job and be happy. It is a text file so is
operating system independent.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

>Unruh wrote:
>> "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> 
>>> Rob wrote:
>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>> Rob wrote:
>>>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>>>> I believe that the O/S vendors supply a file with timezone data.  If you 
>>>>>>> have support, you can even get updates from the vendor.  Since I can't 
>>>>>>> afford support (I'm retired and a hobbyist) I have to do it by hand.
>>>>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>>>>> to operating systems.  Any device that obtains time using NTP and wants
>>>>>> to display it in local time needs the info.
>>>>>> This could just as well be a digital clock.
>>>>> I have a couple of "radio controlled" digital clocks and a wrist watch 
>>>>> that do it automagically.  The VLF broadcast from WWVB provides the 
>>>>> necessary info.
>>>> That cannot be true.  It may work for your location, but I'm sure it
>>>> does not cover the general case under discussion.
>> 
>>> How can it not be true?  The time broadcast encodes both the time 
>>> (standard time) and whether or not DST is in effect.  Of course it 
>>> doesn't work for those jurisdictions that have chosen to go there own 
>>> way as far as DST is concerned.
>> 
>> But there are at least 10 different timezone/DST rules for the USA. How does WWV broadcast
>> them all?

>Sorry, but I believe that only four time zones are sufficient to cover 
>the continental U.S.  If you include Alaska and Hawaii you need two 
>more.  Where did the other four come from?  Of course any jurisdiction 
>CAN make its own rules for DST but most do not.

Aand each timezone needs it DST data, and the exceptions as well (Eg Arizona and
the Navaho nation and then the hopi nation, etc or Saskatchewan in Canada)
I regard a DST timezone as different from a non-DST one. 
 

Rob wrote:
> Uwe Klein <uwe_klein_habertwedt@t-online.de> wrote:
> 
>>Timezone stuff is "Localisation" and handled forex by libc and/or
>>other programming frameworks.
>>
>>And the package manager for "managed" linux distributions ( same for the bsds )
>>usually present timely updates.
> 
> 
> So your standpoint is that every system builder who wants to do
> such localization should be on their own, providing their own update
> mechanism, and there should not be a universal update mechanism for
> timezone updates that is neutral to operating system?

( Hmm,
	You are arguing like our politicians.
	If you are against nonworking censorship of the internet you _must_
	be _for_ the mistreatment of children.
)

Localisation is not really  connected to distributing UTC.
localisation is handled in a number of frameworks. (at the lowest level
	and for unix(ies) libc.
These Frameworks are handled by updatemechanism of your OS/Software Environment.
bsd, rpm or debian updaters ( and they work in a timely fashion if you actually
use the update services, in all my computing years I have not seen any issues
with DST changes ).

Bypassing these things is the next best path to the dll-hell like issues
Microsoft has. where everyone and his grandma think that they have a right
to update random system files.

uwe

David J Taylor wrote:
> Richard B. Gilbert wrote:
>> David J Taylor wrote:
> []
>>> Only for one country out of hundreds.
>>>
>>> David
>>
>> Only ONE is important to me these days!
> 
> I cannot take that view, Richard, as I write software which is used in 
> dozens of countries and time zones.  My software works purely in UTC, 
> and allows the OS to handle time presentation, with or without time-zone 
> information.  A single country solution would be completely unacceptable.
> 
> David

My computers: PC-W/XT, PC/Linux, Sun SPARC/Solaris, and DEC Alpha/VMS 
all keep UTC and display local time.  The installation/setup procedures 
for the few O/Ss I'm familiar with all make provision for setting both 
the time and the time zone.  A few of them even make provision for users 
in multiple time zones with a "TZ" environment variable.

Windows is even fairly good at keeping track of the perpetual tinkering 
that legislatures are prone to.

Rob wrote:

> A similar format but sent as XML could be better.  But it would of course
> be several times bigger.

Generally one only uses XML if one wants a bloated file or to be 
fashionable.  What's wrong with the current Olson source format?

In article <slrnh3k09c.1s1j.nomail@xs7.xs4all.nl>,
 Rob <nomail@example.com> writes:

>So your standpoint is that every system builder who wants to do
>such localization should be on their own, providing their own update
>mechanism, and there should not be a universal update mechanism for
>timezone updates that is neutral to operating system?

Why have a special update mechanism for time zone data?  Why
not piggy back on updating everything else?  Isn't that the
way it works now for most people?

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
> In article <slrnh3k09c.1s1j.nomail@xs7.xs4all.nl>,
>  Rob <nomail@example.com> writes:
> 
>> So your standpoint is that every system builder who wants to do
>> such localization should be on their own, providing their own update
>> mechanism, and there should not be a universal update mechanism for
>> timezone updates that is neutral to operating system?
> 
> Why have a special update mechanism for time zone data?  Why
> not piggy back on updating everything else?  Isn't that the
> way it works now for most people?
> 

It has very little to do with NTP.  NTP is UTC only.  How you torture 
UTC to get your preferred local time is entirely up to you.  You need 
not do it at all if you don't want to.

Kludging local timezone conversions into the NTP protocol somehow would 
be a nightmare if you could persuade anyone to do it!  24 or more 
timezones with more or less arbitrary and constantly changing rules in 
every jurisdiction. . . .   Hundreds of such jurisdictions. . . .

The operating systems I'm familiar with (Windows, VMS, Solaris, & Linux) 
all make some provision for converting UTC to one or more desired 
timezones for display.  Local time, whatever it might be, is *your* 
problem.

In article <Zu2dneTYfMCP4aTXnZ2dnUVZ_hOdnZ2d@giganews.com>,
 "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>Rob wrote:
>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>> Rob wrote:
>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>> Rob wrote:
>>>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>>>> I believe that the O/S vendors supply a file with timezone data.  If you 
>>>>>>> have support, you can even get updates from the vendor.  Since I can't 
>>>>>>> afford support (I'm retired and a hobbyist) I have to do it by hand.
>>>>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>>>>> to operating systems.  Any device that obtains time using NTP and wants
>>>>>> to display it in local time needs the info.
>>>>>> This could just as well be a digital clock.
>>>>> I have a couple of "radio controlled" digital clocks and a wrist watch 
>>>>> that do it automagically.  The VLF broadcast from WWVB provides the 
>>>>> necessary info.
>>>> That cannot be true.  It may work for your location, but I'm sure it
>>>> does not cover the general case under discussion.
>>> How can it not be true?  The time broadcast encodes both the time 
>>> (standard time) and whether or not DST is in effect.  Of course it 
>>> doesn't work for those jurisdictions that have chosen to go there own 
>>> way as far as DST is concerned.

"Standard time" (if you mean EST, PST...) doesn't make much
sense on a signal that covers many time zones.

I'm pretty sure WWVB transmits UTC.  You have to tell your clock
or watch the local time zone.  After that, it will do the 1 hour
offset in the spring/fall.  It will be a day or more late if
reception is poor on the magic night.


>> There you go.  It works for you, but it does not work in the general case.

>I think it works for most people and places.  Most of the US switches 
>to/from DST on the same day.  I don't know about the rest of the western 
>  hemisphere but since I seldom leave the continental U.S. it doesn't 
>really affect me very much.

"works for most people" seems like a silly claim.  What fraction of the
world's population live in the US?  (or within range of WWVB?)


-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
> In article <slrnh3k09c.1s1j.nomail@xs7.xs4all.nl>,
>  Rob <nomail@example.com> writes:
>
>>So your standpoint is that every system builder who wants to do
>>such localization should be on their own, providing their own update
>>mechanism, and there should not be a universal update mechanism for
>>timezone updates that is neutral to operating system?
>
> Why have a special update mechanism for time zone data?  Why
> not piggy back on updating everything else?  Isn't that the
> way it works now for most people?

Because time zone data can be useful for many more systems and
devices than are normally updated by some update service from an
OS vendor.

An NTP synchronized wall clock may not be loading fixes from
Windows Update, but it needs uptodate timezone information.

Hal Murray wrote:
> In article <Zu2dneTYfMCP4aTXnZ2dnUVZ_hOdnZ2d@giganews.com>,
>  "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Rob wrote:
>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>> Rob wrote:
>>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>>> Rob wrote:
>>>>>>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>>>>>> I believe that the O/S vendors supply a file with timezone data.  If you 
>>>>>>>> have support, you can even get updates from the vendor.  Since I can't 
>>>>>>>> afford support (I'm retired and a hobbyist) I have to do it by hand.
>>>>>>> As Jan Ceuleers also pointed out, the problem is not at all limited
>>>>>>> to operating systems.  Any device that obtains time using NTP and wants
>>>>>>> to display it in local time needs the info.
>>>>>>> This could just as well be a digital clock.
>>>>>> I have a couple of "radio controlled" digital clocks and a wrist watch 
>>>>>> that do it automagically.  The VLF broadcast from WWVB provides the 
>>>>>> necessary info.
>>>>> That cannot be true.  It may work for your location, but I'm sure it
>>>>> does not cover the general case under discussion.
>>>> How can it not be true?  The time broadcast encodes both the time 
>>>> (standard time) and whether or not DST is in effect.  Of course it 
>>>> doesn't work for those jurisdictions that have chosen to go there own 
>>>> way as far as DST is concerned.
> 
> "Standard time" (if you mean EST, PST...) doesn't make much
> sense on a signal that covers many time zones.
> 
> I'm pretty sure WWVB transmits UTC.  You have to tell your clock
> or watch the local time zone.  After that, it will do the 1 hour
> offset in the spring/fall.  It will be a day or more late if
> reception is poor on the magic night.
> 
WWVB does transmit UTC!  The clocks have provision for setting the time 
zone.

<snip>

Rob wrote:
> Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
>> In article <slrnh3k09c.1s1j.nomail@xs7.xs4all.nl>,
>>  Rob <nomail@example.com> writes:
>>
>>> So your standpoint is that every system builder who wants to do
>>> such localization should be on their own, providing their own update
>>> mechanism, and there should not be a universal update mechanism for
>>> timezone updates that is neutral to operating system?
>> Why have a special update mechanism for time zone data?  Why
>> not piggy back on updating everything else?  Isn't that the
>> way it works now for most people?
> 
> Because time zone data can be useful for many more systems and
> devices than are normally updated by some update service from an
> OS vendor.
> 
> An NTP synchronized wall clock may not be loading fixes from
> Windows Update, but it needs uptodate timezone information.

Which the owner supplies!  I have two of these gadgets.  One is
a RadioShack  product, the other is a La Crosse Technology WS-8001U
"Radio Controlled Moon Phase Clock".  It's not "NTP Synchronized".  It's 
WWVB synchronized; it receives the WWVB signals in the wee hours of the 
morning when signal reception is good.  It does not provide microsecond 
accuracy but it's certainly good to within plus/minus one second; 
sufficient and even "overkill" for a household clock.

Both of these gadgets allow me to set the time zone; all else is taken 
care of by miracles of modern technology!

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> Rob wrote:
>> Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
>>> In article <slrnh3k09c.1s1j.nomail@xs7.xs4all.nl>,
>>>  Rob <nomail@example.com> writes:
>>>
>>>> So your standpoint is that every system builder who wants to do
>>>> such localization should be on their own, providing their own update
>>>> mechanism, and there should not be a universal update mechanism for
>>>> timezone updates that is neutral to operating system?
>>> Why have a special update mechanism for time zone data?  Why
>>> not piggy back on updating everything else?  Isn't that the
>>> way it works now for most people?
>> 
>> Because time zone data can be useful for many more systems and
>> devices than are normally updated by some update service from an
>> OS vendor.
>> 
>> An NTP synchronized wall clock may not be loading fixes from
>> Windows Update, but it needs uptodate timezone information.
>
> Which the owner supplies!  I have two of these gadgets.  One is
> a RadioShack  product, the other is a La Crosse Technology WS-8001U
> "Radio Controlled Moon Phase Clock".  It's not "NTP Synchronized".  It's 
> WWVB synchronized; it receives the WWVB signals in the wee hours of the 
> morning when signal reception is good.  It does not provide microsecond 
> accuracy but it's certainly good to within plus/minus one second; 
> sufficient and even "overkill" for a household clock.
>
> Both of these gadgets allow me to set the time zone; all else is taken 
> care of by miracles of modern technology!

With a WWVB clock you don't need DST info because the transmitter
provides it.  When you have a NTP clock you don't get any info at
all about DST and you have to calculate it locally.  This requires
either manual action or automatic download of a file that provides
uptodate DST info for a zone whose name is configured one time.

For the US there is no practical difference as the DST rules do not
often change.  In some other countries there are frequent changes.

My house is full of radio clocks.  They work OK because the country
where the signals are transmitted and the country where I live are
in the same timezone, and both countries tend to use the same DST
rules under EU coordination.
However, should the government decide that we should use the local
time that is appropriate for our longitude (instead of the same time
as our neighbors), all my clocks would be off by one hour.
(these clocks are produced for the local market and have no timezone
setting)

These days of the year, sunset is after 10PM here.

In article <qu-dnfrtdPK6Z6fXnZ2dnUVZ_hydnZ2d@giganews.com>,
Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>  ...
>Kludging local timezone conversions into the NTP protocol somehow would 
>be a nightmare if you could persuade anyone to do it!  24 or more 
>timezones  ...

Don't forget that there are places like Newfoundland that don't have a
nice round number of hours offset.

-- 
					-- Rod --
rodd(at)polylogics(dot)com

Rod Dorman wrote:
> In article <qu-dnfrtdPK6Z6fXnZ2dnUVZ_hydnZ2d@giganews.com>,
> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>  ...
>> Kludging local timezone conversions into the NTP protocol somehow would 
>> be a nightmare if you could persuade anyone to do it!  24 or more 
>> timezones  ...
> 
> Don't forget that there are places like Newfoundland that don't have a
> nice round number of hours offset.
> 

That's one of the possibilities that led me to say "24 or more".  I 
don't believe that it's the only one!

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> Rod Dorman wrote:
>> In article <qu-dnfrtdPK6Z6fXnZ2dnUVZ_hydnZ2d@giganews.com>,
>> Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>>>  ...
>>> Kludging local timezone conversions into the NTP protocol somehow would 
>>> be a nightmare if you could persuade anyone to do it!  24 or more 
>>> timezones  ...
>> 
>> Don't forget that there are places like Newfoundland that don't have a
>> nice round number of hours offset.
>> 
>
> That's one of the possibilities that led me to say "24 or more".  I 
> don't believe that it's the only one!

It is not relevant.  The offset from UTC is not the kind of timezone
information that is being discussed here.  It cannot be distributed
via NTP anyway, as the server does not know where the client is and
thus cannot give it the offset info.

The interesting information is the DST schedule in use at the different
areas.  Those are not the same for different areas at the same UTC
offset.  The client will have to know in which area it is and then
can request the timezone information for that area, which tells it
what the offset is at that specific moment.

My recent Linux system has 858 different zone specification files.
More than 24, indeed.

Rob writes:
> The offset from UTC is not the kind of timezone information that is being
> discussed here.

Sure it is.

>  It cannot be distributed via NTP anyway, as the server does not know
> where the client is and thus cannot give it the offset info.

True.

> The interesting information is the DST schedule in use at the different
> areas.

That is part of the timezone data.

> The client will have to know in which area it is and then can request the
> timezone information for that area, which tells it what the offset is at
> that specific moment.

The client may very well need information on zones other than the one it is
located in.  It should check the nearest tzdata server for a standard
tzdata file newer than the one it has and fetch it via a standard protocol
from a well-known location on the nearest of a set of well-known servers.
If it's an embedded system with minimal storage it can throw a way the
stuff it doesn't need.

We have a standard file.  Ftp will do fine as a protocol.  We just need to
agree on a standard location for the current tzdata file and its timestamp
and recruit a distributed set of servers.  The NTP pool servers would do
nicely.  The client to periodically check for new tzdata files would be
trivial.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

On 2009-06-19, John Hasler <john@dhh.gt.org> wrote:

> We have a standard file.  Ftp will do fine as a protocol.  We just need to
> agree on a standard location for the current tzdata file and its timestamp
> and recruit a distributed set of servers.  The NTP pool servers would do
> nicely.  The client to periodically check for new tzdata files would be
> trivial.

Then you have to get the OS aggregators / distributors / vendors to
agree to switch over to utilizing this new TZ data distribution system
instead of their existing package management systems.

Why are we re-inventing the wheel here?

-- 
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - http://support.ntp.org/

Steve Kostecke writes:
> Then you have to get the OS aggregators / distributors / vendors to agree
> to switch over to utilizing this new TZ data distribution system instead
> of their existing package management systems.

Not instead.  The client would be a packaged program which would update the
tzdata without changing anything else.  In Debian I would try to get it
added to the tzdata package.  

> Why are we re-inventing the wheel here?

I don't know of any distribution that provides an easy way arrange for
automatic updates of a single file.  Then there are embedded systems that
have no package-management at all but still may need to know about time
zone changes.

Of course, I am in no position to do anything but talk the idea up here and
maybe write a client, so if no one cares we might as well drop it.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

John Hasler wrote:
> I don't know of any distribution that provides an easy way
>  arrange for automatic updates of a single file.

 Why would rsync not work?
rsync rsync://ftp.eu.openbsd.org/OpenBSD/distfiles/DateTime-TimeZone-0.49.tar.gz .

  or a cron task for wget
 crontab /tasks.crontab
@monthly wget 'ftp://ftp.eu.openbsd.org/pub/OpenBSD/distfiles/DateTime-TimeZone*.tar.gz'


> Then there are embedded systems that have no
>  package-management at all but still may need to know
>  about time zone changes.

.... and, what do all those millions of embedded systems
 do now to get time zone data?


ftp://elsie.nci.nih.gov/pub/tzdata2009j.tar.gz  ?

-- 
E-Mail Sent to this address <BlackList@Anitech-Systems.com>
  will be added to the BlackLists.

E-Mail Sent to this address will be added to the BlackLists <Null@BlackList.Anitech-Systems.invalid> wrote:
> ... and, what do all those millions of embedded systems
>  do now to get time zone data?

They don't.  DST support is usually hardwired, manually configured
or nonexistent.
The user has to set the clock himself twice a year or at best has
to manually enter the start- and end moments.
Or worst, live with incorrect changeover dates (hardwired to US standard).

Rob <nomail@example.com> wrote:
> E-Mail Sent to this address will be added to the BlackLists <Null@BlackList.Anitech-Systems.invalid> wrote:
>> ... and, what do all those millions of embedded systems
>>  do now to get time zone data?
> 
> They don't.  DST support is usually hardwired, manually configured
> or nonexistent.
> The user has to set the clock himself twice a year or at best has
> to manually enter the start- and end moments.
> Or worst, live with incorrect changeover dates (hardwired to US standard).

Newer stuff tends to run a version of Linux or FreeBSD and you get updates
as patches from the maker.

The Axis Communications video encoders and cameras are all that way.


-- 
Jim Pennino

Remove .spam.sux to reply.

Jim Pennino writes:
> Newer stuff tends to run a version of Linux or FreeBSD and you get
> updates as patches from the maker.

Downloaded automatically as needed?  What happens when the maker goes bust,
shuts down their server, or decides the product is obsolete?
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

I wrote:
> I don't know of any distribution that provides an easy way
>  arrange for automatic updates of a single file.

Null writes:
> Why would rsync not work?

It would work fine but it seems like overkill and is not universally
available.

> ...or a cron task for wget crontab /tasks.crontab @monthly wget
> 'ftp://ftp.eu.openbsd.org/pub/OpenBSD/distfiles/DateTime-TimeZone*.tar.gz'

Whatever works.  I'm just proposing that the file be made available at a
standard location on a well-known set of distributed servers.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

John Hasler <john@dhh.gt.org> wrote:
> Jim Pennino writes:
>> Newer stuff tends to run a version of Linux or FreeBSD and you get
>> updates as patches from the maker.
> 
> Downloaded automatically as needed?  What happens when the maker goes bust,
> shuts down their server, or decides the product is obsolete?

The same as any other product, much like the heater/air conditioner
on my house that I replaced because parts were no longer available.

What is this obsession with automatic download some people seem to have?

There have been hundreds and hundreds of patches to each and every OS I run
since the last patch to any time zone information.

Having one more patch for time zones out of hundreds of others is
insignificant.


-- 
Jim Pennino

Remove .spam.sux to reply.

John Hasler <john@dhh.gt.org> wrote:
> I wrote:
>> I don't know of any distribution that provides an easy way
>>  arrange for automatic updates of a single file.
> 
> Null writes:
>> Why would rsync not work?
> 
> It would work fine but it seems like overkill and is not universally
> available.
> 
>> ...or a cron task for wget crontab /tasks.crontab @monthly wget
>> 'ftp://ftp.eu.openbsd.org/pub/OpenBSD/distfiles/DateTime-TimeZone*.tar.gz'
> 
> Whatever works.  I'm just proposing that the file be made available at a
> standard location on a well-known set of distributed servers.

For what kind of system?

While the zoneinfo database, also known as the Olson database, is probably
the most common, it is hardly the only system used.

The information in general has been freely available for years.

General information:

http://www.twinsun.com/tz/tz-link.htm


-- 
Jim Pennino

Remove .spam.sux to reply.

I wrote:
> I'm just proposing that the file be made available at a standard location
> on a well-known set of distributed servers.

Jim Pennino writes:
> For what kind of system?

Any.

> While the zoneinfo database, also known as the Olson database, is
> probably the most common, it is hardly the only system used.

The Olson database is the only one it makes sense to distribute.

> The information in general has been freely available for years.

But only in an ad-hoc fashion.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

John Hasler <john@dhh.gt.org> wrote:
> I wrote:
>> I'm just proposing that the file be made available at a standard location
>> on a well-known set of distributed servers.
> 
> Jim Pennino writes:
>> For what kind of system?
> 
> Any.
> 
>> While the zoneinfo database, also known as the Olson database, is
>> probably the most common, it is hardly the only system used.
> 
> The Olson database is the only one it makes sense to distribute.

What about all the systems that don't use Olson?

>> The information in general has been freely available for years.
> 
> But only in an ad-hoc fashion.

True, the most generally available format is Olson and not everything
uses Olson.

If you limit the problem to Olson, the problem was solved years ago at:

ftp://elsie.nci.nih.gov/pub/

Since 1976 there have been 2 changes to the timezone rules in the US.

The European history is about the same.

The odds are any system you are running today will have been in a trash
heap for years before the rules change for your location again.



-- 
Jim Pennino

Remove .spam.sux to reply.

jimp@specsol.spam.sux.com wrote:

> 
> What about all the systems that don't use Olson?
> 

I'm only aware of one that doesn't require the system administrator to 
manually configure for any zone that that doesn't match the (historic) 
US rules, and that is the Windows NT family.

Jim Pennino writes:
> If you limit the problem to Olson, the problem was solved years ago at:
> ftp://elsie.nci.nih.gov/pub/

Until they have a budget cut, a server reorganization, decide the traffic
is excessive, or just get bored.

> Since 1976 there have been 2 changes to the timezone rules in the US.

There have been two changes to Federal DST rules.  There also have been DST
and/or time zone changes affecting part or all of at least three states.

> The European history is about the same.

> The odds are any system you are running today will have been in a trash
> heap for years before the rules change for your location again.

The Debian tzdata package has been updated 34 times in the last three years
due to changes in the timezone data.
-- 
John Hasler 
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

David Woolley <david@ex.djwhome.demon.co.uk.invalid> wrote:
> jimp@specsol.spam.sux.com wrote:
> 
>> 
>> What about all the systems that don't use Olson?
>> 
> 
> I'm only aware of one that doesn't require the system administrator to 
> manually configure for any zone that that doesn't match the (historic) 
> US rules, and that is the Windows NT family.

HP-UX to name just one mainstream OS doesn't use Olson.


-- 
Jim Pennino

Remove .spam.sux to reply.

John Hasler <john@dhh.gt.org> wrote:
> Jim Pennino writes:
>> If you limit the problem to Olson, the problem was solved years ago at:
>> ftp://elsie.nci.nih.gov/pub/
> 
> Until they have a budget cut, a server reorganization, decide the traffic
> is excessive, or just get bored.

You are still ignoring the fact that all the real OS vendors provide
patches.

>> Since 1976 there have been 2 changes to the timezone rules in the US.
> 
> There have been two changes to Federal DST rules.  There also have been DST
> and/or time zone changes affecting part or all of at least three states.

How many changes have effected YOU since 1976?

>> The European history is about the same.
> 
>> The odds are any system you are running today will have been in a trash
>> heap for years before the rules change for your location again.
> 
> The Debian tzdata package has been updated 34 times in the last three years
> due to changes in the timezone data.

Yeah, for the entire planet.

How many changes have effected YOU since 1976?


-- 
Jim Pennino

Remove .spam.sux to reply.

jimp@specsol.spam.sux.com wrote:
> David Woolley <david@ex.djwhome.demon.co.uk.invalid> wrote:
>> jimp@specsol.spam.sux.com wrote:
>>
>>> What about all the systems that don't use Olson?
>>>
>> I'm only aware of one that doesn't require the system administrator to 
>> manually configure for any zone that that doesn't match the (historic) 
>> US rules, and that is the Windows NT family.
> 
> HP-UX to name just one mainstream OS doesn't use Olson.

I'm not familiar with HP-UX, but SCO OpenServer doesn't, however SCO 
OpenServer falls into my other category, than in which the rules for the 
local timezone have to be entered by the system administrator.  Are you 
saying that HP-UX has centrally distributed rule sets?
> 
> 

jimp@specsol.spam.sux.com <jimp@specsol.spam.sux.com> wrote:
> John Hasler <john@dhh.gt.org> wrote:
>> Jim Pennino writes:
>>> If you limit the problem to Olson, the problem was solved years ago at:
>>> ftp://elsie.nci.nih.gov/pub/
>> 
>> Until they have a budget cut, a server reorganization, decide the traffic
>> is excessive, or just get bored.
>
> You are still ignoring the fact that all the real OS vendors provide
> patches.

And you keep ingnoring the fact that timezone info is not just about
OS vendors.  NTP is a protcol that can be used by anything that wants
to keep correct time, not only by a computer system running a commercial
OS.

> How many changes have effected YOU since 1976?

Isn't it a bit selfish to waive away solutions to a problem that you
have not experienced personally?

Rob wrote:

> And you keep ingnoring the fact that timezone info is not just about
> OS vendors.  NTP is a protcol that can be used by anything that wants
> to keep correct time, not only by a computer system running a commercial
> OS.

This is "localisation" and the TZ*  element is only one small part
of localisation.

Now you want to fix updating this subproblem via parasitic payloading
an essentially unconnected service
thus _bypassing_ the update mechanisms of most major OS distributions.

This is a BadIdea(TM) ( imho and all that jazz ).

uwe

David Woolley <david@ex.djwhome.demon.co.uk.invalid> wrote:
> jimp@specsol.spam.sux.com wrote:
>> David Woolley <david@ex.djwhome.demon.co.uk.invalid> wrote:
>>> jimp@specsol.spam.sux.com wrote:
>>>
>>>> What about all the systems that don't use Olson?
>>>>
>>> I'm only aware of one that doesn't require the system administrator to 
>>> manually configure for any zone that that doesn't match the (historic) 
>>> US rules, and that is the Windows NT family.
>> 
>> HP-UX to name just one mainstream OS doesn't use Olson.
> 
> I'm not familiar with HP-UX, but SCO OpenServer doesn't, however SCO 
> OpenServer falls into my other category, than in which the rules for the 
> local timezone have to be entered by the system administrator.  Are you 
> saying that HP-UX has centrally distributed rule sets?
>> 

HP-UX uses tztab, which is a file format developed by HP.

http://www.informatik.uni-frankfurt.de/doc/man/hpux/tztab.4.html

While HP's system functions overall like most others, the data isn't
Olson.
 

-- 
Jim Pennino

Remove .spam.sux to reply.

Rob <nomail@example.com> wrote:
> jimp@specsol.spam.sux.com <jimp@specsol.spam.sux.com> wrote:
>> John Hasler <john@dhh.gt.org> wrote:
>>> Jim Pennino writes:
>>>> If you limit the problem to Olson, the problem was solved years ago at:
>>>> ftp://elsie.nci.nih.gov/pub/
>>> 
>>> Until they have a budget cut, a server reorganization, decide the traffic
>>> is excessive, or just get bored.
>>
>> You are still ignoring the fact that all the real OS vendors provide
>> patches.
> 
> And you keep ingnoring the fact that timezone info is not just about
> OS vendors.  NTP is a protcol that can be used by anything that wants
> to keep correct time, not only by a computer system running a commercial
> OS.

And you keep ignoring the fact that NTP has nothing to do with local
time.

And that still does not invalidate the fact that vendors provide patches
for the systems they sell, including embedded systems.

>> How many changes have effected YOU since 1976?
> 
> Isn't it a bit selfish to waive away solutions to a problem that you
> have not experienced personally?

The point is that DST updates are a trivial, insignificant issue for
any given person due to their infrequency and the fact that they are
irrelevant unless the change applies to the time zone the individual is
in.


-- 
Jim Pennino

Remove .spam.sux to reply.

On Sat, 20 Jun 2009 22:00:06 +0000, jimp wrote:

> David Woolley <david@ex.djwhome.demon.co.uk.invalid> wrote:
>> jimp@specsol.spam.sux.com wrote:
>> 
>> 
>>> What about all the systems that don't use Olson?
>>> 
>>> 
>> I'm only aware of one that doesn't require the system administrator to
>> manually configure for any zone that that doesn't match the (historic)
>> US rules, and that is the Windows NT family.
> 
> HP-UX to name just one mainstream OS doesn't use Olson.

And AIX.

-- 
2009/06/22:13:14:09UTC Slackware Linux 2.4.32
up 6 days,  3:37,  6 users,  load average: 2.23, 2.23, 2.14