Anthony,
Here is an algorithm that allows the client to display time in client local
time and avoids the problem of the client's clock not being synchronized
with the server's. If we all agree on such a recommendation, then we can
keep the agreement that the client SHOULD display the server times converted
to client local time.
When I suggested that the client display times in client local time, I meant
that the client adjusts the time by the difference between the "time zone"
field of the server and the "time zone" field of the client, which is
normally some multiple of 60 (minutes). But the client does NOT otherwise
adjust the time field, so that the client and printer clocks do NOT need to
be synchronized.
So if the client local time is, say, 8:00 with an offset of 9*60=540 (for
PST) and the server time is 11:05 with a offset of 6*60=360 (for EST), then
the PST client takes the 11:05 time from the server and subtracts 3*60=180
and displays 8:05 to the user.
If the EST printer happens to be configured to use UTC time instead of EST
then its time would have been 17:05 with a offset of 0. In this case, the
PST client would have taken the 17:05 time and subtracted the differences in
the time zone fields (9*60=540) and gotten the same 8:05 local time to
display to the user.
I'll put something like the above in the IIG. I may have the sign wrong for
the "so-called" time zone field, since it is a signed integer. I'll check.
Tom
-----Original Message-----
From: Anthony Porter [mailto:anthony.porter at 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 at cp10.es.xerox.com]
Sent: Tuesday, 27 April, 1999 8:30 PM
To: anthony.porter at 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