I am not sure that the specification should say how the client displays
times. I think that it is more useful if the client displays server times,
together with the current server time. If the client converts times to
local, it is relying on the client and server clocks being synchronized,
with the correct time zones and the proper allowance for summer time.
Anthony Porter
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Tuesday, 27 April, 1999 8:30 PM
To: anthony.porter@computer.org
Cc: 'ipp'
Subject: RE: IPP> MOD - part of Issue 17 - don't need negative
"time-at-xxx" Job Attributes
You said:
>The job-hold-until attribute depends on the time-zone, so a printer that
>supports the "printer-current-time" attribute should support its local
>time zone.
Good point.
In other words, the time zone offset that comes back when a client queries
the "printer-current-time" SHOULD/MUST be the local time of the printer.
If we clarify the "printer-current-time" this way, then a client could also
use the "printer-current-time" to determine the time zone of the Printer,
whether the "job-hold-until" attribute is supported or not. Something that
might be useful for the user submitting a job.
So we should change the clarifying sentence that I added to
"printer-current-time" from:
The time zone in this value NEED NOT be the time zone of the Printer object
or device. Therefore, the vendor MAY ship the implementation using GMT, for
example, with no way to change the time zone. The client SHOULD display any
dateTime attributes using the time zone of the client.
to:
The time zone in this value SHOULD be the time zone of the Printer object
or device. Then the client can use this attribute to determine the time
zone of the printer, even though clients SHOULD display any dateTime
attributes to users using the time zone of the client.
Ok to make this a SHOULD, instead of a MUST?
Other comments?
Tom