1 Correct answer
++ 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 p
...
7
Replies
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.
++EDITED REPLY, fixed many typos and rephrased some lines to clarify explanations
Hi,
You're good, you were very clear from the get go, I wasn't clear because I was reading too fast. But your last reply helped me to get focused on gathering the right answer.
To re-verify, if I understood you correctly, the answer to which standard should be used is a matter of clarity based off of ISO 8601 best practices and principles.
The fact that you asked while using the Adobe/ISO 32000-1:2008 PDF as a reference makes me wonder why is that not fully addressed in that document.
Not only the numerical date/time notations weigh almost exclusively on clarity, but it also matters in a legal context ( as explained here: https://www.jonathanhak.com/2018/01/27/date-and-time-stamp-authenticity/), to include financial business transactions, International communications, aviation, military, etc...
Which numerical notation should be employed as the most convenient method, well, you should go with whatever you believe is more important in your work environment.
If it was up to me, I would consider how my PDF users will understandand and interpret a numerical date/time stamp notation as they work with documents with other computer programs.
It should also matter to a PDF user a how a different representation of the same date/time is notated accross different document types(other than a PDFs) and depending on how such documents are validated against the date/time stamp that is enforced in their machines .
In other words, it is relevant to me to keep an eye on the local date/time stamp that is taken automatically from the system clock.
Assuming that such date/time is always configured correctly in those personal computers, it should also matter how is that data synchronized via Network Time Protocol (NTP) servers to capture the DST offset difference from UT without errors.
That said, it also comes to play the date/time that is also used with their personal mobile devices, in Email communications, or the web sites that are interfaced by means of web browsers, for example.
All of which may express date/time validation notations with similar ISO standards but differently.
Because so many things are involved (or could be involved in your workflow), the whole point of standardization is to provide error-free and accurate validation.
But ultimately it is you, as the developer of that workflow, who defines which standard should be employed (or prefereed over other accepted variants of the same standards) amongst all of your workers in your organization and all of your business partners in order to conduct business effectively with others.
To backup my answer see these next two links:
- https://www.ionos.com/digitalguide/websites/web-development/iso-8601/
- https://www.iso.org/iso-8601-date-and-time-format.html
In addition, you also mentioned :
- If no UT information is specified, the relationship of the specified time to UT shall be considered to be GMT. Regardless of whether the time zone is specified, the rest of the date shall be specified in local time
In the past, GMT used to be employed as a time standard.
Nowadays it is used as a Timezone Designator and it can be used interchangeably with UTC (winter time (or standard time) or summer time (Daylight Saving Time (DST)) timezone designators with offsets.
The only thing that differs between GMT and UTC timezone designators is that the NTP servers need to be calibrated every certain amount of years by a few seconds to keep track of a difference in extra seconds and match that of the GMT local time appropriately.
See slide:
- D:YYYY is the minimum allowed; all else is optional, with specified default values.
Yes, the 4 digit date is the minimum and the main reason is for clarity in regards of inter-communications with different countries other than the US.
In your case, this is very relevant to know because in the US short date expressions such as "02/13/23" creates confusion for people who live in geographical regions outside of North America (where the month is before the day, and the day, the month, and the year expressions consist of a two digit mumerical notation).
In other words, if I was born and raised in France, or better yet, somewhere in an Asian country, I would be struggling figuring out what comes first: the day? the month? or the year?
I would also have a hard time trying to understand the context of the century and the millenia just by looking at the date stamp.
Specially if such document would be referring to a date in the 1900's (or any time before and outside of that era).
Some of this is outlined and explained in the ionos.com website that I posted for you above (first bullet link).
The same applies for a time stamp to represent hours (HH), minutes (MM), seconds (SS), and it can use delimeters such as colon ":", period ".", or dashes "-" which are all accepeted per ISO standards.
The usage of such delimeters is not necessarily relevant to express numerical notations of the Timezone offset.
Both of the apostrophe or the colon symbol may be used with the offset notation.
It aids the user with visual clairty and highlights the hours from the minutes segments (specially when a time-stamp with offset is very small to read for someone who is conducting electronic records compliance audits).
NOTE:
The two digit minutes segment is not really needed with the offset notation.
In my case at work, for example, I frequently process many government PDF forms that require certificate-based digital signatures. They all need validation with a date/time stamp with offset.
The PKI time-stamp protocol requires that a timezone offset is included at the end of that notation.
Such offset notation is based off of the DST, provided that the computer's system clock date and time stamp is configured correctly and also how it correlates to UT as captured by the NTP servers at validation time.
Anyhow, this validation date/time stamps with offset are always printed out very small making it very hard to read (but extremely easy to make mistakes).
So, an offset notation that is trailed after the time stamp segment, like 02:34:56 +08'00', it makes perfect visual clarity to me as opposed to stamping the same line as 02:00:34 +08:00.
- In the above example, it sounds like the trailing 00 or even '00 could be omitted, if desired. I notice that the seconds field was dropped -- this suggests that the date-time and timezone segments are treated separately (?)
Yes, it can be ommited. See my Note above.
In fact, it is very common nowadays to see in airports or commercial websites that include at the end of their hours of operations notation "(UTC -8)" or "(GMT +1)", for example.
This is convenient for travelers or when a person needs to arrange for a business meeting over videochat or phone call.
In which case, a notation like UTC -8 tells me that this is a geographical region that observes DST and falls in a longitude to the West of UT; in which case, I should consider adding 8 hours to my local time prior to the meeting (if everyone that I am communicating with is using a 12-hour clock) .
While UTC +1 tells me that this is a geographical region that observes DST and falls in a longitude to the East of UT; and I should substract one hour from my local time (if everyone that I am communicating with is using a 12-hour clock).
It gets tricky when using a code implementation with the 24-hour clock ISO standard to convert time to or from a 12-hour clock and get the correct timezone offset.
In a 24-hour clock, time starts at 00:00 (zero hundred hours) to express midnight (or 12am if using a 12-hour clock), and up to 23:00 (twenty-three hundred hours) to express 11pm if using a 12-hour clock.
I've also seen offset notations expressed as " -800" or "+100", or when conversion charts are used, just "-8" or "+1" is employed.
Anyway, interestingly enough, the total longitudes are also 24, thus the 24 hours that are accounted for in a 24-hour clock.
Those 24 longitudes include International date time zones [ starting at 0 degree longitude at UT with 11 longitudes (or timezones) that span to the West of UT, and 12 longitudes (or timezones) to the East of UT ].
That also includes the ±180 degree longitude (or UTC ±12:00 if I am not mistaken), which falls within the International dateline boundary at all times].
Every longitude is exactly 15 degrees apart, which is basically an hour (or more specific, 60 minutes).
And as the Earth rotates, the Sun is observed at its highest point at 12 noon at UT (or so humanity was taught) since the inception and full acceptance of the Gregorian Calendar over the Julian Calendar to account for rollover dates, extra hours (or days), and leap years as DST occurs daily in relation to UT all year around.
NOTE:
It would be very interesting to see how a flat-earther would explain all of this this stuff without involving the Christian Bible or the Quran as references...
Not that I am not open to the concept of a flat-earth but LMAO!!! xD just think about it for a moment.
Hell! there are geographical regions in our world that observe up to three or more DST changes in a single day...
How to factor that in accurately per ISO, and expect to get no errors when a script executes a validation ?!?!?
NOTE ENDS
But again, for a date/time stamp, you should stick with whatever the ISOs permit within the accepted universal conventions.
And ultimately, it is you who decides what to ommit or what to define to represent the numerical notation of the offset value with a delimited notation.
That explains why the seconds segment can be dropped and also why (for the sake of the easiest way to express this with computer programming) it is treated separately from the date/time segments.
The point is that it is really a matter of choice if you want to separate hours from seconds with the offset numerical notation by way of using the colon symbol as delimeter or the apostrophe.
Things get a lot trickier if you were using DateTimeGroup (DTG), like in the military.
And even trickiest if you had to plot a gridzone with decimal degrees or nautical degrees combines with a DTG notation.
In which case, when nautical degrees are used, the hours, minutes and seconds are delimited using the following notation:
- 90° 12' 45654" S.
Notice that an offset is not needed because this expression by itslef is just a latitude somewhere in the World and it is not accompanied by a date/time group.
If I am not wrong, 90° is the degree hours, 12' is the minutes, and 45654" the seconds for tgat latitude.
The letter "S" is used to represent a southern latitude (or using the minus ("-") symbol indicates that a latitude is to the South of the Ecuator line).
For the longitude a notaion like 123° 12' 23423" E would be used.
The letter "E" indicates an Easting longitude (or using the ("+") symbol indicates that a longitude is to the East of UT).
If that wasn't enough to cope with, that gridzone degree notation is preceeded by a DTG alpha-numerical notation like:
- "031238NOV2023G"
Where "03" is the day of the month, "1238" is the time in hours and minutes altogether (no ":" delimiter is used with military time), the month is abbreviated with 3 character letters (not a numerical notation).
It is followed by the four digit numerical year notation (YYYY) standard, and lastly, a single character letter to indicate the timezone (or offset), which ranges from A to I, and K to Z.
Letter J is omitted as a timezone designator.
I am mentioning about the DTG standard convention in contrast with other date/time notation standards, because the date/time grouo with offset segment must be explicitely expressed in that format.
The user who writes a date/time in DTG does not enjoy the same optional liberties that you have with your current project.
AdChoices