Skip to main content
P
Phil28073338r0c0
Inspiring
March 13, 2023
Answered

Proper time/date stamp format?

  • March 13, 2023
  • 1 reply
  • 9256 views

I produce PDFs using the PDF::Builder Perl library. It has come to my attention that my library validates as OK timestamps (Creation and Modification dates, etc.) that end with HH'mm, but not HH'mm'. Checking old (1.4, 1.7) Adobe PDF specs, it states that HH'mm' is the correct format; however, the 2008 ISO 32000-1 standard (as published by Adobe), as well as IBM, state that HH'mm is the correct format. Stack Overflow agrees that HH'mm is the ISO standard, although they observe that Adobe products regularly produce the HH'mm' format. No one had seen a Reader (e.g., Acrobat) that wouldn't accept both.

 

So, is there a preferred format? Has there been any statement that one way or the other will not be accepted in the future? Does anyone see any problem with accepting (validating) timestamps in both formats?

    This topic has been closed for replies.
    Correct answer ls_rbls

    It sounds like there may still be some confusion on one of our parts (or maybe both!). What I'm concerned with here is only the format of a user-supplied timestamp for insertion into the PDF file for Creation or Modification date. I am validating it to make sure it's the right format (and plausible content), and I raised this issue because of conflicting definitions among the various PDF references. 2008 was a while ago, and it's even possible that those definitions have been superseded. Even the example given in the Adobe docs doesn't seem to quite match the words (i.e., omitting seconds). I just want to make sure whatever date/timestamp I allow to pass into a PDF file will be acceptable to the vast majority of editors and Readers.

     

    > The two digit minutes segment is not really needed with the offset notation.

     

    Um, I have seen time zones with 30 minute or even 15 minute offsets compared to their neighbors, so I think it's necessary to support minutes of offset. I have no idea what to do with primitive places that use local solar time!

     

    In the future, I may end up assembling a date/timestamp from the system clock and/or other data, so I'd like to be sure of the format. Lots of information in your post (thank you!); maybe I'll get to make use of much of it soon.


    ++ EDITES REPLY,  fixed more typos

     

    You're welcome.

     

    The topic fascinates me and I am learning as I go. So, please excuse me if you spot any discrepancies in my comments that  deviate from the topic.

     

    In any case, my confusion is due to not understaing the context of user date insertion in a file.

     

    All along I've been focused with Date Creation and Modification  from the moment a user digitally signs a PDF document with a certificate-based digital signature.

     

    In which case, the validation process is very straight forward, and the date creation and appearance is defined with the SDK guides, like the Acrobat Digital Signature Workflow Guide.

     

    If you are referring to validating the final result of other actions that a user may employ with Acrobat, such as approving a document with dynamic stamps or custom made annotations,  capturing the date/time when a document is sent/received via email, sharing a file for comments/review,  batch stamping PDF file names with a date/time stamp, exporting/importing date/time stamped documents between Microsoft Office and Acrobat,  combining PDFs files or binding PDFs, or indexing catalogs in a computer system to search and file PDFs that may contain a date/time stamp as a file name, that is the part that I am not clear.

     

    As for the issues that you are concerned with:

     

    • conflicting definitions among the various PDF references. 2008 was a while ago, and it's even possible that those definitions have been superseded.

     

    The PDF references are not enough to cover all aspects.

     

    From what I've read Adobe transferred to ISO.org the managing of the reviewing process.

     

    The reviews on these ISO versions are done every 5 years.

     

    The last review on Adobe ISO 32000-1:2008 version 1.7 was done back in 2018 to reflect changes with newer features that has been added to Acrobat.

     

    • Even the example given in the Adobe docs doesn't seem to quite match the words (i.e., omitting seconds)

     

    It won't match because Adobe/ISO 32000-1:2008 is too ample and doesn't focus on how to handle the  date/time stamps granularity, comparing dates with different precission, nor how to address the aspects of notating an ambiguous   UTC offset with hours, minutes and seconds.

     

    That ambiguity is due to many countries that observe DST based on legal or political reasons, and therefore, those countries that define theirbown DST can  change it without notice.

     

    To work around that ambiguity, and  how the offset should be notated, is referenced (or complemented) with other guides outside of the generic scope defined in the ISOs.

     

    Most recent changes are addressed through normative references and errata references.

     

    ISO 8601 is the most flexible documentation in terms of how to use date/time formats guidelines, and it is widely used nowadays to define date/time creation stamps.

     

    That being the case, you should reference your workflow based of ISO 8601 standard since it does allows the omission of elements (i.e. dropping the minutes and seconds segments in an offset notation), with many different date/time stamp formats.

     

    However, how to work around date/time formats when comparing two or more dates with different precission, and how to define offset granularity in a human-readable form (like adding or dropping  the seconds segment to the offset notation), the ISO standards ( both  Adobe/ISO 32000-1:2008 amd ISO 8601) should be referenced further with a date/time stamp profile.

     

    See in the link below what to consider with specific profiles (described in pages 4-9) of the RFC 3339 below:

     

     

    Also check out this 3WC link:

     

     

    Read the section FORMAT to the end of the document.

     

    It provides a profile that defines two ways of handling the timezone offsets ambiguity.

    1 reply

    ls_rbls
    Community Expert
    ls_rblsCommunity Expert
    Community Expert
    March 14, 2023

    Hi,

     

    I believe that it is not a preferred format, but how the Acrobat JavaScript core interpreter handles the date/time notations.

     

    While the JavaScript portions that are shipped with an operating system will interface with the system clock, web browsers and websites based on ISO date standards, the same is slightly different in Acrobat JavaScript.

     

    For instance, using a time notation as HH'mm to express hours and minutes, in Acrobat JavaScript the uppercase "HH" is reserved to express hour notations. And  upper case "MM" to express minutes.

     

    Using "HH:MM" denotes a 24-hour clock (or military time), while using lower case "h" (or "hh") with uppercase MM  (i.e. h:MM) denotes a 12-hour clock (am or pm).

     

    In Acrobat JavaScript the lower case "m" is reserved to notate the month, not to express time in minutes.

     

    If you are scripting, like for example, using the util.scand() and util.printd() methods, take care of the JavaScript portion in your script to reflect  "HH:MM" or "hh:MM" notations.

    P
    Phil28073338r0c0Author
    Inspiring
    March 14, 2023

    Thanks, but Javascript is not involved here. The full spec (per ISO/IEC 8824 and the ISO/Adobe PDF spec) is

     

    D:YYYYMMDDHHmmSSOHH'mm

     

    where YYYY = year, MM = month 01-12, DD = day 01-31, HH = hour 00-23, mm = minute 00-59, and SS = second 00-59. O is +, -, or Z; HH is hours from UT, mm is minutes from UT. "D:" and " ' " are literally those.

     

    The earlier Adobe PDF specs end with HH'mm'.

     

    So, my question is whether it's important to use (or NOT use) the trailing '. Many Adobe products apparently use the trailing ', but most (if not all) readers seem to be happy supporting either format. When validating a user-specified time/date stamp, would it be reasonable to allow either way (trailing ' or not)? If my library needs to generate a time/date stamp, is one format or the other preferred?

    ls_rbls
    Community Expert
    ls_rblsCommunity Expert
    Community Expert
    March 14, 2023

    I apologize, I misunderstood your requirement completely.

     

    Because I don't know how to script in Pearl, I can't see exactly which part(s) would integrate with Adobe Acrobat as the host program except for when the final PDF is actually opened in Adobe Acrobat.

     

    I would say that the ISO's alone does not entirely dictate a matter of agreement among different entities.

     

    In fact, I think that your very valid inquiry gravitates more towards how the application and usage of the validating process will interact with the system clock (i.e. if it is a Zulu timezone (Z) or a UTC zone with offset, specifically if it observes Daylight Saving Time as defined in: https://www.rfc-editor.org/rfc/rfc3339  and complemented with: https://www.rfc-editor.org/rfc/rfc5544 ).

     

    In which case, if the validation that you need would be required for digital signatures as defined in: https://www.rfc-editor.org/rfc/rfc3161 for PKI Time-Stamp Protocol,  you'll notice that whatever validating mechanism provided in Acrobat (Edit => Preferences => Signatures => Verification) takes the date/time from the users computers system clocks at signiing time (or from whatever time-stamp server is configured internally within an organization to assign the signers PKI time-stamps).

     

    So, if that is what you were inquiring about, such validating time-stampverification is basically defined when a PDF document is finally opened and viewed in Adobe Acrobat Pro.

     

    As far as I was able to test before replying back to you, the time stamp validation looks like this when I change my date/time settings to an UTC zone:

     

     

    While selecting Universal Coordinated Time zone will obviously display automatically the Zulu identifier (Z) instead of an 00'00' offset, shown below:

     

     

    Not sure if this is helpful, but I hope it may be relevant to answer your inquiry and point you in the right direction.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices