Richard B. Gilbert wrote:
Rod Dorman wrote:
In article qu-dnfrtdpk6z6fxnz2dnuvz_hydn...@giganews.com,
Richard B. Gilbert rgilber...@comcast.net wrote:
...
Kludging local timezone conversions into the NTP protocol somehow would
be a nightmare if you could persuade anyone to do it!
John Hasler wrote:
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
Rob wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
John Hasler j...@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
On Sat, Jun 20, 2009 at 5:45 PM, j...@specsol.spam.sux.com wrote:
Yeah, for the entire planet.
How many changes have effected YOU since 1976?
Most of them have affected me or my organization. If you use any form
of calendaring-enabled appliaction (Exchange, Notes, Google calendar,
WebEx, SAP,
On Sat, 20 Jun 2009 22:00:06 +, jimp wrote:
David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote:
j...@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
Todd Glassey CISM CIFI 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
Rob wrote:
Unruh unruh-s...@physics.ubc.ca wrote:
Joe joseph.kr...@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,
j...@specsol.spam.sux.com wrote:
David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote:
j...@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
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
John Hasler j...@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
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
David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote:
j...@specsol.spam.sux.com wrote:
David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote:
j...@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
E-Mail Sent to this address will be added to the BlackLists
n...@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
Rob nom...@example.com wrote:
E-Mail Sent to this address will be added to the BlackLists
n...@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
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
j...@dhh.gt.org
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
John Hasler j...@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
John Hasler j...@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
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
John Hasler j...@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
j...@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
David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote:
j...@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)
John Hasler j...@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
In article zu2dnetyfmcp4atxnz2dnuvz_hodn...@giganews.com,
Richard B. Gilbert rgilber...@comcast.net writes:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
I
Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net wrote:
In article slrnh3k09c.1s1j.nom...@xs7.xs4all.nl,
Rob nom...@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
Hal Murray wrote:
In article zu2dnetyfmcp4atxnz2dnuvz_hodn...@giganews.com,
Richard B. Gilbert rgilber...@comcast.net writes:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert
Rob wrote:
Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net wrote:
In article slrnh3k09c.1s1j.nom...@xs7.xs4all.nl,
Rob nom...@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
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Hal Murray hal-use...@ip-64-139-1-69.sjc.megapath.net wrote:
In article slrnh3k09c.1s1j.nom...@xs7.xs4all.nl,
Rob nom...@example.com writes:
So your standpoint is that every system builder who wants to do
such localization should
On Thu, Jun 18, 2009 at 3:38 PM, David
Woolleyda...@ex.djwhome.demon.co.uk.invalid 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
Rob wrote:
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
Richard B. Gilbert wrote:
Unruh wrote:
Richard B. Gilbert rgilber...@comcast.net writes:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
I believe that the O/S vendors supply a file with timezone data. If
you
have
In article qu-dnfrtdpk6z6fxnz2dnuvz_hydn...@giganews.com,
Richard B. Gilbert rgilber...@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
Rod Dorman wrote:
In article qu-dnfrtdpk6z6fxnz2dnuvz_hydn...@giganews.com,
Richard B. Gilbert rgilber...@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 ...
Richard B. Gilbert rgilber...@comcast.net wrote:
Rod Dorman wrote:
In article qu-dnfrtdpk6z6fxnz2dnuvz_hydn...@giganews.com,
Richard B. Gilbert rgilber...@comcast.net wrote:
...
Kludging local timezone conversions into the NTP protocol somehow would
be a nightmare if you could persuade
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
On 2009-06-19, John Hasler j...@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
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
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
Unruh unruh-s...@physics.ubc.ca wrote:
Joe joseph.kr...@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
Richard B. Gilbert rgilber...@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
Unruh wrote:
Joe joseph.kr...@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
Uwe Klein uwe_klein_habertw...@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
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
David J Taylor david-tay...@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
David J Taylor wrote:
Richard B. Gilbert wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@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
Unruh wrote:
Richard B. Gilbert rgilber...@comcast.net writes:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
I believe that the O/S vendors supply a file with timezone data. If you
have support, you can even get
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:
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
Richard B. Gilbert rgilber...@comcast.net writes:
Unruh wrote:
Richard B. Gilbert rgilber...@comcast.net writes:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
I believe that the O/S vendors supply a file with
Rob wrote:
Uwe Klein uwe_klein_habertw...@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
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
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?
___
David Woolley wrote:
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?
I'm not sure I understand
Hal Murray wrote:
In article slrnh3k09c.1s1j.nom...@xs7.xs4all.nl,
Rob nom...@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
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,
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,
Rob wrote:
Richard B. Gilbert rgilber...@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
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,
Rob wrote:
Richard B. Gilbert rgilber...@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
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
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
Richard B. Gilbert rgilber...@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
On Wed, Jun 17, 2009 at 3:01 PM, Robnom...@example.com wrote:
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
Rob wrote:
Richard B. Gilbert rgilber...@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
Nero Imhard n...@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
David Woolley da...@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.
___
questions
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@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
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
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
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
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
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
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
John Hasler j...@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
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.
___
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
I believe that the O/S vendors supply a file with timezone data. If you
have support, you can even get
Once upon a time, Richard B. Gilbert rgilber...@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
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/
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
Richard B. Gilbert wrote:
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.
Yes, but all the WWVB broadcast says about DST is whether it is
in effect or not, or about to start or end,
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,
Richard B. Gilbert rgilber...@comcast.net writes:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@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
Joe joseph.kr...@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
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.
Richard B. Gilbert wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@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
85 matches
Mail list logo
