It is ok to say that a client SHOULD display times to users using the client
local time?
So when displaying a queue of jobs, I'd like to see the client convert the
time returned by the server from whatever times the server returns to my
local time zone.
I didn't understand the comment about summer time, since my understanding is
that the so-called "time zone" field in the dateTime data type is NOT really
time zone, but rather is the offset in minutes from UTC time (which doesn't
change in summer). So a Printer could have a different offset from UTC time
during summer time than winter time. Or a Printer could always use UTC (or
Zulu) and have the offset be 0 all year long.
Tom
-----Original Message-----
From: Anthony Porter [mailto:anthony.porter@computer.org]
Sent: Wednesday, April 28, 1999 02:12
To: 'Hastings, Tom N'
Cc: 'ipp'
Subject: RE: IPP> MOD - part of Issue 17 - don't need negative
"time-at-xxx" Job Attributes
Tom,
Yes, the time zone should be the local time of the printer. I think that if
the printer supports time, then it must support time zones, and allow the
operator to change it. The operator may have a good reason to set the time
zone to UTC on a particular printer, but it is a problem if the operator
cannot set the local time zone at all.
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