Just replying for the sake of posterity - this was discussed in the Oct. 5 IPP WG meeting, where we decided that "printer-current-time" should be able to hold a value of "unknown". See the minutes from that meeting for details.
Smith
> On Oct 2, 2016, at 10:48 AM, Michael Sweet <msweet at apple.com> wrote:
>> Smith,
>>> On Oct 2, 2016, at 9:03 AM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com> wrote:
>>>> Hi Mike,
>>>> If the Printer has no battery-maintained clock and doesn't have something like NTP configured to allow it to determine the time once it has powered up, it isn't clear to me how the Printer will set the value of "date-time-at-creation" to something other than 'no-value'.
>> Probably the best thing is to omit the attribute if the RTC is not configured when the job is created, or not accept new jobs until the clock is set... But a strict interpretation of the spec would have the Printer copying the 'no-value' from "printer-current-time" to the "date-time-at-creation" attribute.
>>> RFC 2911 section 4.4.30 (https://tools.ietf.org/html/rfc2911#section-4.4.30) says this:
>>>> 4.4.30 printer-current-time (dateTime)
>>>> This Printer attribute indicates the current date and time. This
>> value is used to populate the Event Time Job Description attributes:
>> "date-time-at-creation", "date-time-at-processing", and "date-time-
>> at-completed" (see Section 4.3.14).
>>>> The date and time is obtained on a "best efforts basis" and does not
>> have to be that precise in order to work in practice. A Printer
>> implementation sets the value of this attribute by obtaining the date
>> and time via some implementation-dependent means, such as getting the
>> value from a network time server, initialization at time of
>> manufacture, or setting by an administrator. See [IPP-IIG] for
>> examples. If an implementation supports this attribute and the
>> implementation knows that it has not yet been set, then the
>> implementation MUST return the value of this attribute using the
>> out-of-band ’no-value’ meaning not configured. See the beginning of
>> section 4.1.
>> RFC 2566 (IPP/1.0) did not have the second paragraph... Under our current guidance for 'no-value' and 'unknown' usage, this attribute SHOULD report 'unknown' when the date and time is not yet configured since, like "printer-geo-location", there is always a current date and time - the value is merely unknown.
>> We should discuss whether to change this to 'unknown' when RFC2911bis hits AUTH48 at our Wednesday conference call.
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4956 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20161011/919cbb6e/attachment.p7s>