From: ltso@phoenix.london.waii.com (Marc Brett) [-/+]
Date: 13 Jun 1996 09:27:42 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Solaris vs SunOS
X-Keywords: implementation [-/+] multicast [-/+] peer [-/+]
Wendy,
There are three versions of the NTP protocol: 1, 2, and 3.
The xntpd daemon (versions 3.xx) will accept requests from all three
versions and respond in the correct dialect. It can also request time
from servers and peers running NTP 1 or 2, but in that case the "server"
or "peer" statement in /etc/ntp.conf needs to have the correct "version"
parameter specified:
Eg:
server very.old.timserv.com version 1
server newer.timserv.com version 2
server latest.and.greatest.timserv.com # Implicit NTP V3
I'd be surprised if any NTP V1 implementation has been written for
Solaris 2.x. Did Solaris 2.x even exist when NTP V2 was finalized??
Wendy Shutter (shutter@digicomp.com) wrote:
: For the moment I'm going to give up on my socket problem on SunOS and
: ask a slightly different question:
: Can ntp v3.4x (beta multicast) on a Solaris 2.4 machine talk to servers
: using ntp v1.4 on SunOS machines?
: If this will work, are there any gotchas I should careful of?
: If this won't work, can I compile ntp v1.4 on Solaris 2.4?
: Thanks.
: -- Wendy Shutter (shutter@digicomp.com)
--
Marc Brett Marc.Brett@waii.com
Western Geophysical Tel: +44 181 560 3160 ext. 4178
From: rid@pst.cfmu.eurocontrol.be (Jim Reid) [-/+]
Date: 12 Jun 1996 13:14:27 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Help Needed: Slewing clocks with ntpdate [-/+]
X-Keywords: adjtimed [-/+] HP-UX [-/+] Mills [-/+] release [-/+]
>>>>> "Tom" == Tom Lane <tgl@netcom.com> writes:
Tom> I've submitted a patch that makes adjtimed work more like the
Tom> standard adjtime(2) call on other systems, to wit, apply a
Tom> small slew rate over a long period of time to implement a big
Tom> delta. Dunno if Mills has incorporated this change into the
Tom> xntp release, however. xntpd itself only ever asks adjtimed
Tom> to do a small slew, so adjtimed's limitation doesn't hurt it,
Tom> and Mills was iffy about fixing something that wasn't broken
Tom> for his purposes.
And quite right too. adjtimed is an ugly, ugly hack to get round HP-UX
brain damage. For some reason known only to themselves, H-P did not
put the adjtime() system call in their OS. So instead of ~100 lines of
kernel code, H-P users have had to put up with a daemon talking to
xntpd through SysV IPC (ugh!) to patch kernel variables while the OS
executes (double ugh!). Thankfully, H-P have seen the light with HP-UX
10. This has the adjtime() system call, almost a decade after it first
appeared in BSD Unix.
Adding functionality to adjtimed is a waste of effort, given that it
will die - at long last! - once H-P's customers move to the most
recent OS distribution.
From: tgl@netcom.com (Tom Lane) [-/+]
Date: Thu, 13 Jun 1996 05:18:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Help Needed: Slewing clocks with ntpdate [-/+]
X-Keywords: adjtimed [-/+] adjustment [-/+] HPUX [-/+] Mills [-/+] syslog [-/+]
rid@pst.cfmu.eurocontrol.be (Jim Reid) writes:
>>>>>> "Tom" == Tom Lane <tgl@netcom.com> writes:
Tom> Mills was iffy about fixing something that wasn't broken
Tom> for his purposes.
> Adding functionality to adjtimed is a waste of effort, given that it
> will die - at long last! - once H-P's customers move to the most
> recent OS distribution.
Which is likely to take a *lot* longer than you seem to think.
Do you know what HP's official estimate is of the sysadmin time
needed to upgrade an HPUX 9.x installation to 10.x?
Forty manhours, that's what.
That's direct sysadmin time, not counting lost user time.
And that's very probably a rose-tinted-glasses view of reality.
Certainly for someone like me, with a huge amount of non-HP
software installed (ntpd, for example ;-)), the transition
is unlikely to be painless.
Last I checked, 10.x wasn't free, either.
It's fairly likely that my 715 workstation isn't *ever* going to
get upgraded to 10.x. I'll decide I need a new machine before
I have a week to spare for busywork like an OS upgrade.
I think it's worth the trouble to fix adjtimed to work like it
ought to work, given that many other people are probably putting
off the OS upgrade just like I am. The fact that unpatched adjtimed
doesn't work like real adjtime() *is* visible to users of the ntpd
package. There's the problem with ntpdate complained of at the
start of this thread, and there's problems with frequent syslog error
messages about "time adjustment didn't complete" (which is what
originally drove me to poke into adjtimed to begin with).
regards, tom lane
From: rid@pst.cfmu.eurocontrol.be (Jim Reid) [-/+]
Date: 13 Jun 1996 11:32:43 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Stratum Documentation [-/+]
X-Keywords: peer [-/+] VAX [-/+]
>>>>> "mkovacs" == mkovacs <mkovacs@ibm.net> writes:
mkovacs> I will be putting together an NTP system of about 500
mkovacs> nodes consisting of a mix of VAX, SUN, IBM PC, Mac, and
mkovacs> HP systems. I am looking for some way to document which
mkovacs> client goes with which server. I will be breaking the
mkovacs> system down into strata since not all systems will need
mkovacs> super accurate time. What I need is to be able to
mkovacs> document where everything goes so that in the event of
mkovacs> trouble there is at least some chance of determining
mkovacs> where the problem lies. I haven't seem this problem
mkovacs> addressed and want to know if there is some sort of
mkovacs> method that I have overlooked.
Simple. Define 3 or 4 stratum N servers. These are your master time
sources. These peer with each other and some external sources - other
NTP servers or radio clocks. At least one of these systems should have
a stable time of day clock for backup. If/when you lose the main clock
or your internet link, these can fall back to a semi-decent TOD clock
that won't drift too much.
You then select some number of stratum N+1 servers. These peer with
each other and with your stratum N servers. You should arrange these
N+1 servers in groups of 6 or so. ie Each group of six peers with each
other and with the stratum N servers. Typically, these stratum N+1
servers will be department file/mail server. The stratum N+2 systems
will be for end-users: workstations, PCs and Macs. These just take
time from their local stratum N+1 server and perhaps another 1 or 2
such servers nearby. This way, all is not lost if xntpd on the local
server fails.
Write this down. Add some information on troubleshooting - ie how to
use xntpdc - and logging and there you have it. It's no big deal. If
you set up the time distribution correctly - and it's hard to get that
wrong - NTP and your time syncronisation will take care of itself.
From: fitz@think.com (Tom Fitzgerald)
Date: 14 Jun 1996 01:08:36 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: NTP Stratum Documentation [-/+]
X-Keywords: broadcast [-/+] Cisco [-/+] VAX [-/+]
mkovacs@ibm.net writes:
> I will be putting together an NTP system of about 500 nodes consisting of
> a mix of VAX, SUN, IBM PC, Mac, and HP systems. I am looking for some
> way to document which client goes with which server. I will be breaking
> the system down into strata since not all systems will need super accurate
> time.
> What I need is to be able to document where everything goes so that in the
> event of trouble there is at least some chance of determining where the problem
> lies.
> I haven't seem this problem addressed and want to know if there is some sort
> of method that I have overlooked.
After a point, I feel it's easier to do *everything* with directed
broadcasts from a single timeserver, and "broadcastclient yes" on
everything else. The general scheme I've used is:
Two systems (main and backup) sync with the outside world and with
each other. Both use their local software clocks if the outside link
is down, but main is two strata better than backup.
Main broadcasts on every local net, using:
broadcast 123.123.1.255
broadcast 123.123.2.255
etc, etc, potentially a long list.
except where the local routers don't allow directed broadcasts, in
which case one convenient system (or the router itself, if it's a
Cisco) have "server main preferred ; server backup ; broadcast
123.123.123.255" to handle local broadcasting duties.
Every system on the net, other than main, backup, and the local
rebroadcasters (if any) has "broadcastclient yes".
Backup normally does no broadcasting. It has a copy of main's config
file, so that if main dies for more than a couple of hours, backup's
xntpd can manually be killed and re-run up with main's config file, so
that it can do all the broadcasting itself (until main comes up
again).
There are only 3 or 4 distinct configurations:
- main
- backup
- local broadcasters, one per net with no directed broadcasts (if any)
- everyone else
The manual intervention required when main dies is simple enough, and
rare enough not to be a problem. There are no failures that can cause
part of the net to diverge off into a time different from the rest of
the net.
If this is heresy, I'd like to hear criticism of it - this scheme has
worked well for me.
--
Tom Fitzgerald Thinking Machines Corp, Bedford MA, USA A3FC3545C031E735
fitz@think.com (617)276-0400 x4848 3DE72FB31F6028D1
From: ltso@phoenix.london.waii.com (Marc Brett) [-/+]
Date: 17 Jun 1996 13:42:31 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Zones [-/+]
X-Keywords: AIX [-/+] DST [-/+]
GG (gauth@imaginet.fr) wrote:
: After an endless search on the Web, I was unable to find a
: somewhat comprehensive list of TZ acronyms that cover different
: areas all around the world.
: Does any one knows where to find such a list ?
Yes! In Markus Kuhn's excellent Web pages, I found this:
>From <http://www.ft.uni-erlangen.de/~mskuhn/iso-time.html>:
Arthur David Olson <ado@elsie.nci.nih.gov> maintains a database of
all current and historic time zone changes. It is availabe via ftp
from <ftp://elsie.nci.nih.gov/pub/> in the "tzcode*" and "tzdata*"
files. Most Unix time zone handling implementaions are based on this
package. If you want to join the tz@elsie.nci.nih.gov mailing list,
which is dedicated to discussions about time zones, please send a
short message to tz-request@elsie.nci.nih.gov.
Send them a message at tz@elsie.nci.nih.gov if you know of a time zone
which has changed. Portugal just did, and a small town in Kent is
planning to revive its own local time zone -- 5 min 41 sec ahead of GMT!
: Another question : how does a computer tell from Daylight
: Saving Time what the proper time is. Here in France, the precise date
: when we switch from GMT-2 to GMT-3 changes from year to year.
: There's no way for to make an algorithm out of this!
: So, what does the acronym MET-DST mean ? Does it work 'magically'
: or, mundane option, do I have to set it up manually (GMT-2 <-> GMT-3)
: when the time changes every 6 month ?
Every computer is different. Unix machines generally keep their
time-of- day clock at UTC, and every application is responsible for
correctly converting this to local time, usually through a common set of
C routines.
On our AIX machines, the time zone is defined in an environment variable
TZ which is defined as:
Norway: TZ=NFT-1DST,M3.5.0,M9.5.0
UK: TZ=GMT0BST,M3.5.0,M10.4.0
Texas: TZ=CST6CDT
--
Marc Brett Marc.Brett@waii.com
Western Geophysical Tel: +44 181 560 3160 ext. 4178
From: rid@pst.cfmu.eurocontrol.be (Jim Reid) [-/+]
Date: 18 Jun 1996 10:13:33 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Zones [-/+]
X-Keywords: daylight [-/+] DST [-/+] reset [-/+] timezone [-/+]
Paul> In article <4q2u1h$ec6@avalon.imaginet.fr>, GG
Paul> <gauth@imaginet.fr> wrote:
>> After an endless search on the Web, I was unable to find a
>> somewhat comprehensive list of TZ acronyms that cover different
>> areas all around the world. Does any one knows where to find
>> such a list ?
Paul> I don't think you'll find it. AFAIK there is no such set of
Paul> worldwide timezone abbreviations upon which everyone agree.
Indeed. For example BST can mean Bering Straits Time or British Summer
Time. This sort of ambiguity is why some people use +/-HHMM notation
to denote the delta between local time and GMT/UTC. ISTR the military
use a single letter to unambiguously denote local time.
>> Another question : how does a computer tell from Daylight
>> Saving Time what the proper time is. Here in France, the
>> precise date when we switch from GMT-2 to GMT-3 changes from
>> year to year.
For most UNIX systems, this is done by consulting an environment
variable - TZ - to find out the time zone the process is using. The
value of this variable is used to locate a file - usually in
/usr/lib/zoneinfo. This file holds the information about the zone -
how much ahead/behind UTC it us, when/if daylight savings time is used
and how much the clocks change during daylight savings time.
UNIX systems keep to UTC/GMT internally. Utilities like the date
command use TZ and the files in /usr/lib/zoneinfo to map that UTC
timestamp to the prevailing local time.
Paul> Isn't France running on MET (Mean European Time)? Don't you
Paul> change between GMT-1 and GMT-2 ?
>> There's no way for to make an algorithm out of this!
Paul> Sure there is! The switch occurs on the last sunday in
Paul> March and September, doesn't it? Starting in 1996 summer
Paul> time ends on the last sunday of October instead. There are
Paul> algorithms for this....
You're both right. There are algorithms which do this, but only when
the rules are defined. For most of Europe, an EU directive is followed
to determine when daylight savings time is used. However, this
directive is only valid until 1997 or 1998 and non-EU nations have no
obligation to follow it. In short, the dates for applying DST can be
put into an algorithm, but only once the politicians and bureaucrats
decide what the rules are going to be. For instance, before this EU
directive, the UK decided the dates for DST on a year-by-year basis.
>> So, what does the acronym MET-DST mean ? Does it work
>> 'magically' or, mundane option, do I have to set it up manually
>> (GMT-2 <-> GMT-3) when the time changes every 6 month ?
This means that Middle European Time - Daylight Savings Time. In other
words, the system date convertion/printing routines consult the file
for MET in the zoneinfo directory and pay attention to the rules
listed there for daylight savings time. If the current date is during
a period of DST, the time of day is advanced/retarded by the amount
required by the prevailing DST rules.
Paul> It's much simpler than that: the C runtime library uses the
Paul> U.S. date for switching between standard time and summer
Paul> time. Which of course makes it pretty useless in other
Paul> areas of the world.
Wrong. UNIX keeps GMT/UTC internally and maps this to the local time
by consulting a file given by the TZ environment variable. Some US
vendors have an irritating habit of shipping software configured for
Pacific Standard Time,
Paul> Your options:
Paul> 1. If you have the runtime source code available, modify it
Paul> so it changes between standard and summer time according to
Paul> European rules. Remember that our rules have changed this
Paul> year!
Nonsense. Just set TZ to point at a suitably configured zoneinfo file
for the local time zone.
Paul> 2. Otherwise your only option will be to set TZ=GMT-2, and
Paul> then manually change it to TZ=GMT-3, and then reset it, at
Paul> the proper dates.
Nonsense. Just set TZ to point at a suitably configured zoneinfo file
for the local time zone.
Paul> 3. A third option is to forget about summer time and always
Paul> run your system clock at standard time - or even at GMT!
Nonsense. Just set TZ to point at a suitably configured zoneinfo file
for the local time zone.
From: bpier@itds7.hac.com (Bill Pier)
Date: 18 Jun 1996 17:22:08 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Is there an NTP client for OS/2 [-/+]
In message <4q579n$4gd@klein.nis.newscorp.com> - mcdoug@ultranet.com (Doug
McPherson)Tue, 18 Jun 1996 03:22:15 GMT writes:
:>
:>I'd like to get NTP clients installed on our OS/2 servers (we have
:>quite a few). They're all running OS/2 WARP.
:>
:>Any pointers?
:>
:>Thanks in advance
:>/doug
:>Doug McPherson
:>Innovative Telecom Corp
:>Nashua, NU 03060
:>Email: mcdoug@ultranet.com
:>
Yes, there are several. One of the nicest is a PM app
called Time868.
It can be found at ftp-os2.nmsu.edu.
Bill
--------------------------------------------------------------------------
Bill Pier bpier@itds7.hac.com
--------------------------------------------------------------------------
From: dlm@firebird.osf.org ( Dan Murphy ) [-/+]
Date: 18 Jun 1996 19:30:39 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Looking for Stratum numbers
X-Keywords: documentation [-/+] peer [-/+] RFC [-/+] synchronized [-/+]
In article <835098441.486879@orion.didata.co.za> mallwri@orion.didata.co.za (Mark Allwright) writes:
> I found out, so here goes :-
> Stratum 0 Directly connected to a time source
> Stratum 1 One hop from that time source
> Strarum 2 Two hops from that time source
> etc.
> Found at http://news.janet.ac.uk/documents/NTP/ntp-guide.html
Well, that's not consistent with the NTP documentation. The
following is excerpted from RFC 1305, the NTP Version 3 document:
Stratum (sys.stratum, peer.stratum, pkt.stratum): This is an
integer indicating the stratum of the local clock, with values
defined as follows:
0 unspecified
1 primary reference (e.g., calibrated atomic clock,
radio clock)
2-255 secondary reference (via NTP)
Hence, a machine directly synchronized to a reliable external time
source (WWV, GPS, atomic clock, etc) would report itself as
stratum 1.
Any machine which is synchronizing to another machine reports
itself as 1 greater than the machine to which it is synchronizing.
dlm
From: robk@oldtimer.win-uk.net (Robin Kimberley) [-/+]
Date: Wed, 19 Jun 1996 08:34:47 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Help
X-Keywords: reset [-/+]
In article <31C77B79.5D01@ctc.net>, Vince Hayes (walhayes@ctc.net) writes:
>Help Can I set my pc to automatically reset the time and date when I log on to the
>internet my e-mail address is walhayes@ctc.net
>
Vince,
Try the EXCELLENT "Dimension 4" by Rob Chambers. (robc@thinkman.com)
I've been using it for a few weeks, and it is the best one I've
found so far.
Rob Kimberley
From: Mike Pelletier <mikep@comshare.com> [-/+]
Date: 19 Jun 1996 12:48:53 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Enquiry about DST in the U.S. [-/+]
X-Keywords: daylight [-/+] DST [-/+]
In article <Matthew.Healy-1906961145100001@pudding.med.yale.edu>,
Matthew D. Healy <Matthew.Healy@yale.edu> wrote:
>In article <4q88s6$n9k@avalon.imaginet.fr>, stylweb@imaginet.fr (GeyGey) wrote:
>
>: I live in France and I don't know how DST switching date is calculated
>: in the U.S.A. Could any one explain this to me ? Thank You.
>
>On the 1st Sunday in April, switch to daylight time at 2:00 local std time
>
>Last Sunday in October , switch back at 2:00 AM daylight time
>
>With most flavors of Unix, one simply sets the TZ variable to
>something like EST5EDT (for Eastern USA).
Also, the states of Indiana and Arizona do not observe Daylight Savings
Time. In the case of Indiana, they alternate between Eastern Standard
Time and Central Daylight Time, with the net result being their time does
not change at all. The UNIX TZ variable can be set to "EST5CDT" to get
this behaviour.
From: thompson@robin.tezcat.com (Bob Thompson)
Date: Wed, 19 Jun 1996 16:07:12 CDT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Enquiry about DST in the U.S. [-/+]
X-Keywords: daylight [-/+]
In article <4q9b1l$g0a@valhalla.comshare.com> Mike Pelletier <mikep@comshare.com> writes:
>Also, the states of Indiana and Arizona do not observe Daylight Savings
>Time. In the case of Indiana, they alternate between Eastern Standard
>Time and Central Daylight Time, with the net result being their time does
>not change at all. The UNIX TZ variable can be set to "EST5CDT" to get
>this behaviour.
> -Mike Pelletier.
Close. The parts of Indiana that are in the Central time zone (two areas, one
near Chicago, one down around Evansville) do observe daylight time. The rest
of the state is in the Eastern time zone and does not observe daylight time.
This means that, during the summer, the entire state has the same
time, although differently realized (EST and CDT) , while in the winter, the
two areas are an hour apart.
========================================
/bob/
thompson@robin.tezcat.com (Bob Thompson)
=========================================
From: ratzka@hrz.uni-marburg.de
Date: 20 Jun 1996 15:30:49 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Enquiry about DST in the U.S. [-/+]
X-Keywords: DST [-/+]
Also, the states of Indiana and Arizona do not observe Daylight Savings
Time.
To make things more complicated: if I remember right the Navajo
reservations in Arizona do observe DST...
--
Wolfgang Ratzka, HRZ Uni Marburg
Mail: Hans-Meerwein-Str., D-35032 Marburg, Germany
Email: <ratzka@hrz.uni-marburg.de>
Phone: +49 6421 28 5876 // FAX: +49 6421 28 6994
From: gwinn@res.ray.com (Joe Gwinn) [-/+]
Date: Wed, 26 Jun 1996 21:38:17 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Help,on NIST Phone contact information, requested [-/+]
X-Keywords: dial [-/+]
Try: US Naval Observatory Master Clock: 202-762-1401
and: WWV audio: 303-499-7111
In article <31D165FE.C1@mink.mt.att.com>, "P. Rallabhandi"
<kamu@mink.mt.att.com> wrote:
> We have been told that there are some centres that provide UTC time if
> Contacted through phone. ( Not for dial up modem purposes, but for
> manual verification). We appreciate if any one having information about
> such phone numbers, can share it with us.
>
> Thank you for your time,
>
> -Prabu Rallabhandi
From: David Woolley <david@djwhome.demon.co.uk> [-/+]
Date: Wed, 19 Jun 1996 21:46:10 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Time Zones [-/+]
X-Keywords: Linux [-/+] SCO [-/+] timezone [-/+]
In article <osrard34ya.fsf@heron.pst.cfmu.eurocontrol.be>,
Jim Reid <rid@pst.cfmu.eurocontrol.be> wrote:
>
> Paul> It's much simpler than that: the C runtime library uses the
> Paul> U.S. date for switching between standard time and summer
> Paul> time. Which of course makes it pretty useless in other
> Paul> areas of the world.
>
>Wrong. UNIX keeps GMT/UTC internally and maps this to the local time
>by consulting a file given by the TZ environment variable. Some US
>vendors have an irritating habit of shipping software configured for
>Pacific Standard Time,
One needs to remember that there is no single true Unix.
Early Unices had the US changeover rules hard coded and TZ could only
be used to modify the names and offset (which had to be an integral
number of hours - a problem for the 100s of millions of people in India
which are on -0530, and a few other timezones).
In modern Unices, there are two methods. One method uses the zoneinfo
database (which is freely available in source and included on most, if
not all Linux CDs and which has a lot of commentary about the history
of the changeover rules. This has the advantage that it is possible
to change the rules on the fly, although I suspect programs have to be
written specially to re-read the rule files.
The other method encodes the time rules in the TZ environment variable
itself. SCO Unix (3.2v4.2) only supports this method. The default is to
use the US changeover dates. It is impossible to change the rules
for long running processes unless they are restarted, as daemons inherit
the TZ value from the system initialisation script.
There is also a kernel timezone variable, in many Unices, although modern
software tends to ignore this.
As already pointed out, many suppliers supply Unix localised to Berkeley,
rather than to the place where they are selling it, and many new Unix
users don't understand that it needs to run internally in UTC.
MS-DOS is a different problem, as it runs in local, wall clock, time,
and timezone support has lagged behind Unix.
--
David Woolley, London, England david@djwhome.demon.co.uk
From: dey@teleport.com (Norbert Dey)
Date: 21 Jun 1996 13:12:16 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Enquiry about DST in the U.S. [-/+]
X-Keywords: DST [-/+]
In <thompson.1470.001A2E3E@robin.tezcat.com>, thompson@robin.tezcat.com (Bob Thompson) writes:
>In article <alrafxyli0m.fsf@pprz04.HRZ.Uni-Marburg.DE> ratzka@hrz.uni-marburg.de writes:
>
>
>> Also, the states of Indiana and Arizona do not observe Daylight Savings
>> Time.
>
>>To make things more complicated: if I remember right the Navajo
>>reservations in Arizona do observe DST...
>>--
>>Wolfgang Ratzka, HRZ Uni Marburg
>>Mail: Hans-Meerwein-Str., D-35032 Marburg, Germany
>>Email: <ratzka@hrz.uni-marburg.de>
>>Phone: +49 6421 28 5876 // FAX: +49 6421 28 6994
>
>That's correct. However, whether the Navajo Nation regards itself as
>being "in" Arizona or merely surrounded (mostly) by Arizona is another
>question<G>.
And (as the story goes) the Hopi Nation, which is surrounded by the
Navajo Nation, does not observe DST.
From: harvey@indyvax.iupui.edu (James Harvey)
Date: 21 Jun 96 22:23:48 -0500 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Enquiry about DST in the U.S. [-/+]
X-Keywords: daylight [-/+] DST [-/+] HP-UX [-/+] panic [-/+] timezone [-/+]
In article <4q9b1l$g0a@valhalla.comshare.com>, Mike Pelletier <mikep@comshare.com> writes:
> In article <Matthew.Healy-1906961145100001@pudding.med.yale.edu>,
> Matthew D. Healy <Matthew.Healy@yale.edu> wrote:
>>In article <4q88s6$n9k@avalon.imaginet.fr>, stylweb@imaginet.fr (GeyGey) wrote:
>>
>>: I live in France and I don't know how DST switching date is calculated
>>: in the U.S.A. Could any one explain this to me ? Thank You.
>>
>>On the 1st Sunday in April, switch to daylight time at 2:00 local std time
>>
>>Last Sunday in October , switch back at 2:00 AM daylight time
>>
>>With most flavors of Unix, one simply sets the TZ variable to
>>something like EST5EDT (for Eastern USA).
>
> Also, the states of Indiana and Arizona do not observe Daylight Savings
> Time. In the case of Indiana, they alternate between Eastern Standard
> Time and Central Daylight Time, with the net result being their time does
> not change at all. The UNIX TZ variable can be set to "EST5CDT" to get
> this behaviour.
Umm, just plain EST5 is preferable, thank you. I first discovered this
odd idea that we "alternate between Eastern Standard Time and Central
Daylight Time" while configuring some HP systems here last fall. When
configuring the timezone after the system installation, HP-UX gives you
a menu choice for "Indiana Eastern" that results in the odd kludge you
mentioned. The parts of Indiana in the Eastern time zone stay on EST
all year round. The parts in the Central time zone (in the NW near Chicago
and SW near Nashville TN) alternate between Central Standard Time and Central
Daylight Time. So it's EST5 in the east and CST5CDT in the NW and SW.
It is true that the numbers stay the same, but if someone who actually knows
that we ignore DST starts seeing date/times with CDT at the end they might
panic and think that you have set the clock or something else wrong too.
BTW, what the heck does this all have to do with NTP?
--
James Harvey harvey@iupui.edu Disclaimer: My opinions; I don't speak for IU.
Do you like acoustic music? Don't miss Cornstock '96 in Indianapolis at
Southeastway Park, July 13-14. See http://www.nitemusic.com/nm/ for details!
From: Tom Van Baak <tvb@zso.dec.com>
Date: 27 Jun 1996 20:07:38 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,sci.geo.satellite-nav
Subject: Re: The Millennium Comes Early to GPS
X-Keywords: precision [-/+] reset [-/+]
gwinn@res.ray.com (Joe Gwinn) wrote:
>I am posting this to the NTP newsgroup because GPS is one of the primary
>time sources used with NTP.
>
>I have good news and I have bad news.
>
>The good news is that GPS will not have a "Year 2000" problem.
>
>The bad news is that GPS System Time will roll over at midnight 21-22
>August 1999, 132 days before the turn of the millennium. On 22 August
>1999, unless repaired, many or all GPS receivers will claim that it is 6
>January 1980, 23 August will become 7 January, and so on. I would expect
>that some manufacturers have already solved the problem, but many have
>not.
A number of us use the Motorola Oncore GPS receiver for
precision timing and so this issue is of interest to us.
I called Motorola and found out that the Oncore will not
have any problem during GPS weeks 1023/4 in August 1999.
The Oncore uses the year value last stored in NVRAM to
disambiguate which 19.6-year window the 10-bit TOW value
is relative to.
There are two ways the Oncore will report the wrong date:
1) Buy an Oncore from the factory, put it in a closet
for 20 years, and then power it up for the first time.
The reported date will be in 1996 instead of 2016.
2) Hard reset the Oncore, and before it acquires its
first satellite, manually set the date to a very
wrong year; e.g., 20 or 40 years in the future.
From: rid@pst.cfmu.eurocontrol.be (Jim Reid) [-/+]
Date: 21 Jun 1996 10:42:12 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: ntpdate "Can't adjust the time of day: No such file or directory"
X-Keywords: adjtimed [-/+] adjustment [-/+] HP-UX [-/+]
John> Executing ntpdate on my HP-UX 9.05 715 gives the following
John> error: Can't adjust the time of day: No such file or
John> directory
John> However, if I run it with the "-d" switch, it seems to work
John> fine. Another exception I've noted is that it will work
John> without the "-d" if my system time is more than 0.5 seconds
John> off from the NTP server(s).
John> Any idea what the error message is trying to tell me?
The error message is caused by the absence of the adjtime() system
call. Prior to HP-UX 10, HP didn't ship kernels that supported
adjtime(). [The 100 or so lines of code required have been in BSD for
at least a decade. Oh well.] To get round this, someone came up with
adjtimed. This pokes around /dev/kmem fiddling the kernel's time
variables, using SysV message queues (ugh!) to communicate with xntpd
to exchange clock kludge values. If the message queue is not present,
attempts to change the clock will fail with the above error message.
[The message queue isn't a file, but let that pass.]
Now ntpdate can either step the clock - ie by calling settimeofday() -
or else call adjtime() to gradually sync the clock. [For old HP-UX,
the ntp code has an adjtime() routine which mimics the real thing and
does all this nonsense with message queues to get adjtimed to patch
/dev/kmem.] Take a look at clock_adjust() in ntpdate.c. You will see
there that ntpdate will normally just call settimeofday. However if
the time adjustment is small (< NTPDATE_THRESHOLD == 0.5s), ntpdate
will use adjtime() to brink the clock into line.
From: Mike Pelletier <mikep@comshare.com> [-/+]
Date: 26 Jun 1996 17:00:26 -0400 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Don't want xntpd server to update system clock
X-Keywords: broadcast [-/+] configuration [-/+] DTS [-/+]
In article <4qrv29$a65@sjx-ixn2.ix.netcom.com>,
Erik Basilier <basilier@ix.netcom.com> wrote:
>
>I am looking at a configuration where existing DTS software owns the
>system clock, updating it to reflect a GPS receiver connected by
>RS-232. The objective is to install an NTP stratum 1 server on the same
>node, such that NTP clients can get time from this very accurate node.
I see, I think the confusion I was encountering was due to the fact
that you could also use xntpd to read the time from the RS-232 GPS
clock, didn't realize you were using other software to handle the
system/GPS clock synchronization.
I think what you're looking for is:
The "pll" flag enables the server to adjust its local
clock, with default enable (on). If not set, the local
clock free-runs at its intrinsic time and frequency
offset. This flag is useful in case the local clock is
controlled by some other device or protocol and NTP is
used only to provide synchronization to other clients.
So you'd put "disable pll" in your ntp.conf file to let it trust the
system clock.
>Under what conditions does a stratum 1 server modify its local system
>clock?
Based on input from an attached atomic, WWV broadcast, or GPS clock
under the control of the xntpd process.
From: Terje Mathisen <Terje.Mathisen@hda.hydro.com> [-/+]
Date: Fri, 21 Jun 1996 22:30:46 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: [++] Re: Time Zones [-/+]
X-Keywords: daylight [-/+] DST [-/+] update [-/+]
GG wrote:
[snip]
> Another question : how does a computer tell from Daylight
> Saving Time what the proper time is. Here in France, the precise date
> when we switch from GMT-2 to GMT-3 changes from year to year.
> There's no way for to make an algorithm out of this!
> So, what does the acronym MET-DST mean ? Does it work 'magically'
> or, mundane option, do I have to set it up manually (GMT-2 <-> GMT-3)
> when the time changes every 6 month ?
The best solution I've found so far is to use a pretty convoluted TZ
string format, which is understood by Win95, WinNT and several Unix
systems (that's where I got it from):
TZ=MET-1MEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
This should be fairly self-explanatory: The time zone names (which
doesn't really matter) are MET and MEST, with -1 and -2 hours offset
from UTC.
Following the semicolon are the rules for when to switch:
M3.5.0/02:00:00 means to switch to daylight savings time on M(onth) 3,
week 5 (i.e. the last week), day 0 (i.e. sunday), at local time 02:00.
The switch back should then take place at 03:00 on the last sunday of
october.
This is the current rule for all of the EC as well as Norway which are
bound by EC regulations in this matter.
If (when?) they decide to change the rules again, I'll have to write a
little routine to automatically update all the machines.
--
- <Terje.Mathisen@hda.hydro.com>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
From: WhiskerP@logica.com (Peter Whisker) [-/+]
Date: Mon, 24 Jun 96 07:57:22 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: [++] Re: Time Zones [-/+]
X-Keywords: daylight [-/+] DST [-/+] timezone [-/+] update [-/+]
In article <31CB0676.4C36@hda.hydro.com>, Terje Mathisen <Terje.Mathisen@hda.hydro.com> wrote:
>GG wrote:
>[snip]
>> Another question : how does a computer tell from Daylight
>> Saving Time what the proper time is. Here in France, the precise date
>> when we switch from GMT-2 to GMT-3 changes from year to year.
>> There's no way for to make an algorithm out of this!
>> So, what does the acronym MET-DST mean ? Does it work 'magically'
>> or, mundane option, do I have to set it up manually (GMT-2 <-> GMT-3)
>> when the time changes every 6 month ?
>
>The best solution I've found so far is to use a pretty convoluted TZ
>string format, which is understood by Win95, WinNT and several Unix
>systems (that's where I got it from):
>
> TZ=MET-1MEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00
>
>This should be fairly self-explanatory: The time zone names (which
>doesn't really matter) are MET and MEST, with -1 and -2 hours offset
>from UTC.
>
>Following the semicolon are the rules for when to switch:
>
>M3.5.0/02:00:00 means to switch to daylight savings time on M(onth) 3,
>week 5 (i.e. the last week), day 0 (i.e. sunday), at local time 02:00.
>
>The switch back should then take place at 03:00 on the last sunday of
>october.
>
>This is the current rule for all of the EC as well as Norway which are
>bound by EC regulations in this matter.
>
>If (when?) they decide to change the rules again, I'll have to write a
>little routine to automatically update all the machines.
>
If you look at ftp://louie.udel.edu/pub/ntp you will see lots of
programs concerning timezones and NTP.
The "tz" stuff has a "date" program and a set of timezone files. There is a
large document at the top which explains how timezones in almost every country
in the world have worked since the 1840's ! It also gives the DST change dates
going back to the last century and explains the current rules. It is
interesting reading.
Until they next change the rule (!), the EU has set the last Sunday in
October/last Sunday in March as a general rule for the whole of Europe
(including the British Isles).
Peter
************************************************************
* Peter Whisker * Logica UK Ltd, Cobham, Surrey, UK
*Any opinions are mine!* http://www.logica.com/ for theirs !
* whiskerp@logica.com * http://public.logica.com/~whiskerp/
For PGP key:Send e-mail to pgp_peter@reepicheep.logica.co.uk
Fingerprint:FD 97 98 9A F4 1E 9C 89 8B 8D FF 73 65 A0 E1 99
From: bpenrod@nbn.com [-/+]
Date: 22 Jun 1996 06:58:24 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Is there an NTP client for OS/2 [-/+]
X-Keywords: monitoring peer [-/+] release [-/+] TrueTime [-/+]
In <4q579n$4gd@klein.nis.newscorp.com>, mcdoug@ultranet.com (Doug McPherson) writes:
>I'd like to get NTP clients installed on our OS/2 servers (we have
>quite a few). They're all running OS/2 WARP.
>
>Any pointers?
>
>Thanks in advance
>/doug
>Doug McPherson
>Innovative Telecom Corp
>Nashua, NU 03060
>Email: mcdoug@ultranet.com
>
Have patience, soon I will be placing just such a daemon on our ftp site. I was forced
to write one to support the development of our NTS-100 family of NTP servers. Though
it is not a direct port of the Mill's style daemon, it follows the intent and is able
to keep the OS/2 system clock within one tick (31.25 ms) of UTC. It will peer with up
to 22 NTP servers, the replies from which are ensembled via an optimal weighting scheme.
Since my original purpose was to create a client daemon for debug and monitoring of our
NTP servers, I have included data logging capabilities so that the performance of each
server which is being queried may be individually observed by pulling the file into a
spreadsheet and graphing it.
It is a windowed, multi-threaded text mode app with a simple function key interface
and has been quite stable for the last three or four months. I need only clean up a few
things to make it more idiot proof and write the manual before I will be ready to
release the beta version.
Bruce Penrod
TrueTime Inc
Santa Rosa, CA
From: Judah Levine <jlevine@boulder.nist.gov> [-/+]
Date: 27 Jun 1996 13:09:38 GMT [-/+]
Newsgroups: comp.protocols.time.ntp
Subject: Re: Help,on NIST Phone contact information, requested [-/+]
X-Keywords: dial [-/+] NIST [-/+]
"P. Rallabhandi" <kamu@mink.mt.att.com> wrote:
>We have been told that there are some centres that provide UTC time if
>Contacted through phone. ( Not for dial up modem purposes, but for
>manual verification). We appreciate if any one having information about
>such phone numbers, can share it with us.
>
>Thank you for your time,
>
>-Prabu Rallabhandi
You can get a voice announcement of the time by calling
(303) 499 7111. The voice message there is the same as the messages
transmitted by our radio stations WWV and WWVH. The time is announced
just before the start of each minute, and each second is identified by
a tick. There is no tick on the 29th and 59th second of each
minute.
Judah Levine
Time and Frequency Division
NIST Boulder
From: Metod Kozelj <metod.kozelj@rzs-hm.si> [-/+]
Date: Thu, 27 Jun 1996 15:27:36 +0200 [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.setup
Subject: Re: Linux & NTP - should I update the system clock before halt? [-/+]
X-Keywords: dialup [-/+] Linux [-/+]
Hello,
Amos Shapira wrote:
> I have a stardard setup of Linux (Debian) and a dialup modem PPP connection
> to an ISP.
>
> I run xntpd which picks up remote servers when I'm connected (after a
> while, is there a way to stir it to check as soon as I'm up, BTW?)
>
> I wander if I should run the program to set the system clock while
> halting Linux, so it gets set from what NTP knows. It could be that
> ntp never got to talk to the internet on some sessions, but most of
> the time when my machine is on it is connected at least part of the
> time (pulling mail, for instance).
>
> If it is so obvious, then why no distribution which includes xntp does
> this?
I too run xntpd. The difference is that I don't
start it at boot time, but rather when my
SLIP session successfuly launches. I kill the
daemon when closing the SLIP session and
I set the CMOS clock at that very moment
too.
Why do I do it that way? All PC's I work with
have lousy timekeeping. The clock drifts
from the exact time when they are off and
(usually) even more when they are on. If
the xntpd daemon just starts to talk to
remote servers, it (at first) gets just
terrible offsets. After a while it resets
the system time, but it's idea of
system clock's drifing rate. If, on the
other hand, I start xntpd when starting
the SLIP session, I first synchronize
my system clock to remote servers using
command 'ntpdate' (thus the system time
is correct), then I start xntpd and it's
task is just to maintain the correct time.
There is a mechanism to maintain the correct
time built in xntpd even if the remote
servers are not accessible. But for that
it has to run for some days, constantly
synchronizing to remote servers, so it
can get an idea of drifting of system clock.
It writes the drifting information to
a file (usually in /usr/local/etc/ntp.drift).
Setting the CMOS time is very special feature
of PC-based unices while xntp distribution
is intended for wast majority of unices.
I guess that's why no hint on these
peculiarities is given.
With kind regards,
Metod
--
Metod Kozelj
e-mail: Metod.Kozelj@rzs-hm.si
WWW: http://www.rzs-hm.si/people/Metod.Kozelj/
From: dlm@firebird.osf.org ( Dan Murphy ) [-/+]
Date: 27 Jun 1996 18:01:05 GMT [-/+]
Newsgroups: comp.protocols.time.ntp,comp.os.linux.setup
Subject: Re: Linux & NTP - should I update the system clock before halt? [-/+]
X-Keywords: adjustment [-/+] Linux [-/+]
In article <87u3vxcvnr.fsf@birnam.dsi.co.il> amos@dsi.co.il (Amos Shapira) writes:
> I wander if I should run the program to set the system clock while
> halting Linux, so it gets set from what NTP knows. It could be that
> ntp never got to talk to the internet on some sessions, but most of
> the time when my machine is on it is connected at least part of the
> time (pulling mail, for instance).
Here's what I've done on my home system which is also only
intermittently connected to a source of reference time:
1. As part of the script establishing a SLIP/PPP connection, I
run ntpdate to correct (hopefully by adjustment) my local
clock.
2. Since the clock is only corrected once/day typically, I run
a little utility that calls ntp_adjtime to set the "frequency"
of the system clock for better long-term accuracy in the absence
of a synchronization source. I determined the frequency
manually by observing the ntpdate correction for several days
and tweaking the frequency accordingly. Some of the crystals
on PCs are way off from the expected (standard? ha ha)
frequency, but with the frequency correction applied by
ntp_adjtime, the timekeeping is good to within about 0.5
second/day.
3. I almost never halt my system, but setting the cmos clock
from the system clock before shutdown would be a good idea if
the system clock has been maintained as above. There is a
little utility ( clock ) that will do that for you. I believe
it comes with most distributions.
This may seem cludgy given all the cleverness in ntpd, but it
makes a big improvement in the timekeeping for machines not
permanently connected to the net.
It's a big help that Linux has ntp_adjtime. If anyone want my
utility or shell scripts, send mail.
dlm