This only works if the server operator has set the time and time zone
correctly, and it seems that this is usually not the case, especially when
summer time involved.
Some operators will set local time, and leave the time zone as 0(UTC),
others will set the correct time and time zone eg PST, but when summer time
arrives, some will just change the clock and leave the zone at PST, some
will change the zone to PDT and leave the clock, and some will do nothing at
all. For my fax at home, I set the local summer time when I bought it in
the summer, and don't bother changing it in the winter.
Returning the age of the event in seconds (job creation, start and
completed) avoids these problems. The client can use the age to calculate a
reliable local client time.
The problem here is that IPP 1.0 already defines these attributes as
returning the printer-up-time.
The client could get the printer-up-time at first contact with the printer,
calculate the origin of printer-up-time in client local time and then use it
to calculate the client local time of job events. This also avoids any
problems with wrong clocks.
The problem there is that the client does not know if the server has
rebooted and reset the printer-up-time in between two requests. Some jobs
will have zero for the event, but more recent jobs will have values relative
to a new printer-up-time.
Perhaps it does not matter very much. A server with a clock can maintain
its printer-up-time between reboots,even if the clock is wrong so that the
printer-up-time reflects time since installation. The client can also
refresh the printer-up-time periodically whenever it gets some other
attribute from the printer.
As the IPP 1.1 clock shows 2 seconds before midnight, I suggest then that we
keep the attributes as they are, drop the datetime-at-xxx attributes and add
clarifactions that:
If possible the server should maintain the printer-up-time between resets
or reboots.
Clients should requery printer-up-time periodically because the server may
have reset it.
This is not watertight, but probably maximizes the chances of the client
displaying correct times for job events.
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: 05 May 1999 10:20
To: anthony.porter at computer.org; 'Hastings, Tom N'
Cc: 'ipp'
Subject: RE: IPP> MOD - part of Issue 17 - don't need negative
"time-at-xxx" Job Attributes [and IIG]
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