A simple statement such as in my previous email...
"Do the best you can to obtain the correct local time."
Or to restate from your email...
"The time does not have to be that precise in order to work in
practice."
The specification of a tolerance in this case is not appropriate. Here
words much are better.
Ron Bergman
Hitachi Koki Imaging Solutions
On Fri, 30 Apr 1999, Manros, Carl-Uno B wrote:
> Ron,
>
> I think Tom was just trying to come up with some kind of indicator that the
> time does not have to be that precise in order to work in practice, most of
> the time. Some people seem to have assumed that the time has to be
> absolutely exact.
>
> Do you have a more generic way of saying it?
>
> Carl-Uno
>
> > -----Original Message-----
> > From: Ron Bergman [mailto:rbergma@dpc.com]
> > Sent: Friday, April 30, 1999 2:07 PM
> > To: Hastings, Tom N
> > Cc: ipp@pwg.org
> > Subject: RE: IPP> Last Call Comment: Job and Printer time attributes
> > shou ld be REQUIRED
> >
> >
> > Tom,
> >
> > I have watched this discussion go into various states of disarray. It
> > seemed to finally settle into a reasonable reality, until I saw this
> > latest message.
> >
> > Don't we just want to say... "Do the best you can to obtain
> > the correct
> > local time." ? Why are you trying to put a tolerance on
> > this? So if I
> > can't guarantee +/- 5 minutes, I better not report clock
> > time? What is so
> > magical about 5 minutes? (Normally during the day I don't
> > know the time
> > to the nearest hour... but I degress.)
> >
> > The specification should be precise where required. If
> > precision is not
> > required, no tolerance need be specified.
> >
> >
> > Ron Bergman
> > Hitachi Koki Imaging Solutions
> >
> >
> >
> > On Fri, 30 Apr 1999, Hastings, Tom N wrote:
> >
> > > Patrick,
> > >
> > > We agree that we don't want to mandate an accurate time.
> > >
> > > How about adding a clarification to the Printer's
> > "printer-current-time"
> > > attribute like:
> > >
> > > The accuracy of the value MAY be on the order of plus or
> > minus five
> > > minutes.
> > >
> > > Tom
> > >
> > > -----Original Message-----
> > > From: papowell@astart4.astart.com
> [mailto:papowell@astart4.astart.com]
> > Sent: Tuesday, April 27, 1999 17:29
> > To: hastings@cp10.es.xerox.com;
> > SHIVAUN_ALBRIGHT@HP-Roseville-om2.om.hp.com
> > Cc: ipp@pwg.org
> > Subject: RE: IPP> Last Call Comment: Job and Printer time attributes
> > shou ld be REQ UIRED
> >
> >
> > > From ipp-owner@pwg.org Tue Apr 27 12:05:43 1999
> > > From: "Hastings, Tom N" <hastings@cp10.es.xerox.com>
> > > To: SHIVAUN_ALBRIGHT@HP-Roseville-om2.om.hp.com
> > > Cc: ipp@pwg.org
> > > Subject: RE: IPP> Last Call Comment: Job and Printer time attributes
> shou
> > > ld be REQ UIRED
> > > Date: Tue, 27 Apr 1999 12:00:22 -0700
> > >
> > > Shivaun,
> > >
> > >
> > > How about adding the following sentence to the "printer-current-time"
> > > attribute:
> > >
> > > An implementation MAY support this attribute by obtaining the date and
> > time
> > > by any number of implementation-dependent means at startup or
> > subsequently.
> > > Examples include: (1) an internal date time clock, (2) from the
> operator
> > at
> > > startup, (3) from HTTP headers supplied in client requests, and (4) from
> > the
> > > network, using NTP [RFC1305] or DHCP option 32 [RFC2132] that returns
> the
> > > address of the NTP server. If an implementation supports this attribute
> > by
> > > obtaining the current time from the network (at startup or later), but
> the
> > > time is not available, then the implementation MUST return the value of
> > this
> > > attribute using the out-of-band 'no-value' meaning not configured. See
> > the
> > > beginning of section 4.1.
> > >
> > > Since the new "date-and-time-at-xxx" Job Description attribute refer to
> > the
> > > "printer-current-time", they will be covered also.
> >
> > I am totally blown away at all this discussion about time.
> >
> > I will simply note that of the various locations that I have
> > visited (over a couple of dozen this month), only 1 (one) had the
> > SERVER time within 1 minute of WWV, and this was because it periodically
> > went out and got it from a WWV receiver.
> >
> > I think that this standards group needs a bit of a reality check.
> >
> > I suspect strongly that the 'no-value' will become the operational
> > standard.
> >
> > Patrick Powell
> >
>