ietf-nntp Section 11.5 - NEWNEWS

[Lee Kindness]

Paul Overell writes:
 > Lee Kindness <lkindness at csl.co.uk> writes
 > >Why? What in the spec requires an accurate time? I believe the DATE
 > >command should return an arbitrary string/token - The client shouldn't
 > >care in the slightest what it parses to - DATE is only really being
 > >used to mark/note the time of the last NEWNEWS (or NEWGROUPS) command
 > >issued. Clients should file this away and then resurrect it (and parse 
 > >it slightly) for sending as an argument to the next NEWNEWS/NEWGROUPS
 > >call...
 > Requiring NEWNEWS and NEWGROUPS to use the "arbitrary string/token" from
 > the DATE command is an incompatible change from RFC977.
 > RFC977 does not have the DATE command so RFC977 conforming clients have
 > to obtain UTC from their own sources.
 > The only way to be compatible with RFC977 is if NEWNEWS and NEWGROUPS
 > take UTC, therefore DATE must return UTC.

I still think that DATE should return the UTC time, however I don't
think we should be getting worked up about it. The only point that we
should be building up a time to send to NEW* is on the first
connection to a certain server - on subsequent connections we should
used a cached value from an earlier DATE command. Thus the accuracy of 
the returned time is of no importance, we are automatically
synchronising to the servers time.

 > >The DATE command MAY be accurate.
 > You can't mean this - using MAY would imply that a server could *always*
 > return 111 11111111111111 and still claim to be compliant!

Ok, SHOULD.