ietf-nntp Section 11.5 - NEWNEWS
paulo at turnpike.com
Fri Nov 17 10:04:39 PST 2000
-----BEGIN PGP SIGNED MESSAGE-----
In article <G462G6.9n6 at clw.cs.man.ac.uk>, Charles Lindsey
<chl at clw.cs.man.ac.uk> writes
>In <ylaeazmy6f.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu>
>>Paul Overell <paulo at turnpike.com> writes:
>>> Clive D.W. Feather <clive at demon.net> writes
>>>> + The date and time are given in the server's approximation to UT
>>>> + (otherwise known as GMT).
>>No, it's not; it's UTC. The only reason why it was called GMT was because
>>folks didn't understand the technical difference between GMT and UTC.
>>Most server implementations that I'm familiar with use gmtime to obtain
>>the information, and on nearly all Unix systems this will return UTC (on
>>some, it will return TAI).
>May I suggest
>+ The date and time are given in the server's approximation to UTC
>+ (commonly referred to as GMT).
"the server's approximation to" is redundant - any secondary UTC clock,
no matter how accurate, is going to be approximate.
>And will somebosy please explain to me what "TAI" is?
To quote from http://cr.yp.to/proto/utctai.html
What is TAI?
TAI, Temps Atomique International (French for International Atomic
Time), measures real time. One second of TAI time is a constant duration
defined by cesium radiation. TAI has been measured continuously since
1955 and is the foundation of all civil time standards.
TAI times are identified by year, month, day, hour, minute, and second.
There are exactly 86400 TAI seconds in every TAI day. TAI days are
labelled by the Gregorian calendar.
What is UTC?
One day of Earth's rotation isn't exactly 86400 seconds. It's closer to
86400.002 seconds, wobbling slightly from day to day.
UTC, Coordinated Universal Time, is based on TAI, and very similar to
it, except that UTC has leap seconds every year or two.
However, discussing TAI is a red herring, the only time scale we are
concerned with is UTC.
>I don't think we need to care if the server is out by several minutes
>even, since it should not concern us. That is more than enough to work out
>what the server's time zone is.
Why would anyone care what the server's time zone is?
>The only command that cares about time is NEWNEWS.
> If we ask for all
>articles received on the server since 001116 031219, then what we actually
>want is "all articles received since the last time I asked you, which was
>at 001116 031219 according to my reckoning". The problem is that the time
>quoted in the NEWNEWS came from the clock on MY machine, and the server
>will respond according to the clock on ITS machine. So both machines need
>to be accurate for perfect performance.
Exactly. Which is why servers SHOULD be accurate.
> A more realistic solution would be
>for people to include an overlap (a few minutes) in the time they give in
>the NEWNEWS command, since it does little harm if a few duplicate
>Message-IDs are received.
>Maybe there should be a NOTE to suggest exactly that.
This is good defensive client behaviour to deal with servers' inaccurate
clocks - but it does not justify servers' having inaccurate clocks.
Paul Overell T U R N P I K E
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
-----END PGP SIGNATURE-----
More information about the ietf-nntp