Bob,
In that case the job-hold-until attribute is not much use as it is. Perhaps
it is better if the job-hold-until attribute specified a dateTime value?
When the printer is tended by an operator, it is not uncommon for the
operator to put certain jobs on hold until a certain time, particularly if
the job requires special media, or handling. The job-hold-until attribute
would let user see when the job is likely to be printed.
Anthony
-----Original Message-----
From: Herriot, Robert [mailto:Robert.Herriot at pahv.xerox.com]
Sent: Tuesday, 27 April, 1999 10:03 PM
To: Hastings, Tom N; anthony.porter at computer.org
Cc: 'ipp'
Subject: RE: IPP> MOD - part of Issue 17 - don't need negative
"time-at-xx x" Job Attributes
I don't think that we can mandate what the time zone should or must be.
A printer vendor can certainly set a printer's clock (if it exists) to the
correct time in some time zone at time of manufacture. GMT is likely the
best choice for the time zone. But a vendor cannot know what time zone a
printer is going to be installed in, nor does it matter. A customer may want
to change the time zone or may not care to bother.
A client must be able to translate a received time, which must include a
timezone, into a local time. But a client should not expect for the received
times to say anything about the time zone used by people near the printer.
That is overloading the intent of the time attributes which is intended to
give the absolute time of occurrence of various events.
As for "job-hold-until", it is certainly ambiguous whether "evening" is
relative to the client or server. Because there is no requirement that a
client tell the server about its time zone, the "job-hold-until" attribute
must be relative to the server. Because the model document doesn't specify
what "evening" or any other time period means, a client cannot infer from a
"printer-current-time" clock when evening is. It might likly be somewhere in
the range of 1700-2400, but the model is purposefully silent on this issue.
Bob Herriot