Use of Date Stamps for simple version control is acceptable for documents that change fast and frequently and are not under strict release control. Although Time Stamps can be used in Document Contents and in the Filename, they should be reserved for fast-changing work or in very specific high-scrutiny scenarios. Automated systems commonly use Time Stamps for specific situations and they are supported by very tightly managed algorithms. Humans, however, will have trouble with not only getting the initial formatting for the Time Stamp creation correct, but also in the interpretation of it.
For any content under strict revision control, such as Company Policies and Standards, Procedures, Document, Client Contracts and Agreements, or Client-facing detailed Checklists, a proper Version Notation control should be used in the Document Content or in the Filename. Please see the appropriate section below for details on using the Date and Time Stamps or Version Notation.
Date Stamps, Time Stamps and Version Notation each have their own purpose and appropriate use. Combining the use of Stamps and Version Notation for the same content can end up being redundant and confusing if not done properly. The straight line, general method for application should be to use either Stamps or Version Notation, not both. If both are used, it should be with a clear understanding of why and for how long both will be maintained.
For example: It makes sense to use a Date Stamp for a document being collaborated on by many people as it is brought from Version 3.0 to 3.1. The document will have an internal notation of the current version on the first page of the document. Once version 3.1 is released with the Version Notation updated on page one, the Date Stamp would be stripped off the filename and the document released to the wild.
This document does not attempt to discuss or consider version control available or imposed by document management and collaboration systems such as Alfresco, SharePoint, LifeRay, GitHub, etc. If any of these systems are used, their effect on your Date Stamps, Time Stamps, and Version Notation must not only be considered, but if incorporated or relied upon in any way, must also be documented in the appropriate or relevant standards and procedures document.
The default format used for date and time begin with and stem from the International standard ISO 8601 (Representation of dates and times) defines unambiguous written all-numeric big-endian format for dates, such as 1999-12-31 for 31 December 1999, and time, such as 23:59:58 for 23 hours, 59 minutes, and 58 seconds.
Date Stamps can be used in the Document Content and in the Filename, so long as there is a standardized method adopted and called out in the Company Standards and Procedures document.
Documents where it is acceptable to use a Date Stamp as the simple version include basic checklists, client data files, and marketing material being developed.
• All Date Stamps used in Filenames should be in the form YYYYMMDD, e.g. 20141213
• The stamp can also be presented with dashes or periods between the Year, Month and Day: YYYY-MM-DD or YYYY.MM.DD.
e.g. 2014-12-13 or 2014.12.13
• It is not acceptable to separate any portion of the Date Stamp with spaces.
• If only the Year and Month are being used, it would look like this:
201412 or 2014-12 or 2014.12
• When adding a Date Stamp to a Filename, it should be appended to the end of the name so as not to obscure the actual document name.
• The Date Stamp and the Filename can be separated by a space, dash, or space-space as long as they are separated by some character.
e.g. Filename-2014.12.13.docx or Filename 2014.12.13.docx or
Filename – 2014.12.13.docx
• If you have multiple files created on a given day (for example, iterations of a configuration file), you may add a letter(s), such as:
• You should never abbreviate the year to only YY or two digits, e.g. 141213
• All Date Stamps used in Document Content should follow the standard writing and grammar rules for your country or region.
E.g. 13 December 2014 or December 13, 2014, etc.
Adding Time Stamps to Date Stamps
• Refer to the Time Stamp section below for specific rules about Time Stamps.
• Date Stamps can be combined with Time Stamps if necessary, but should only be used if absolutely necessary as it can quickly become cumbersome and confusing.
• For Filenames, this is usually left to automated systems that create files, such as graphic or audio file management systems, not human-created and handled files.
• For Filenames or in Document Content, if the Time Stamps are added to Date Stamps, follow the Time Stamp guidelines in the Time Stamp section below and the specified Time Stamp Company Standard when doing so.
Time Stamps can be used so long as there is a standardized method adopted and called out in the Company Standards and Procedures document. The standard must including the clear details of the unique scenarios in which it is acceptable to use Time Stamps.
Time Stamps should rarely be used without Date Stamps. If there is no information indicating the date of the document (in the filename or the content), the Time Stamp will likely be of little use. And relying on the file management structure creation or touch date is not universally standardized, so it will be of no help.
Documents where it is acceptable to use a Time Stamp as the simple version include media flies (such as graphics, audios, videos), log entries or log files, and in/on most documents related to security or quality control.
Note: Time stamps in the format outlined below are not to be used in an actual filename as it would create an “illegal” filename for any OS. The only valid option would be to substitute the full colon symbol for an acceptable character.
• All Time stamps used in filenames or technical content will be in the 24-hour Military format: HH:MM
The Military format is used because there is no confusion about AM or PM and it is more efficient.
• All Time stamps used in client-facing document content will be in the 12-hour UTC format: HH:MMAM/PM UTC for easily human readable, international format.
E.g. 9:40PM EST
• The Time stamps should always include both the Hour and the Minute at a minimum.
• The default should be a conservative Time stamp with only Hours and Minutes.
• If you have multiple files at the same time (for example, iterations of a configuration file), you might add a letter, such as:
• The Time stamp can include Seconds by simply adding SS to the end of the stamp, such as:
Adding Time Stamps to Date Stamps
• Refer to the Date Stamp section above for specific rules about Date Stamps.
• When a Time Stamp is added to a Date Stamp in the filename, it should be appended following a single dash “-” to the end of the date stamp.
e.g. Filename with Date of 2014, December 13th @ 9:40pm => Filename-2014.12.13-21.40
With seconds added: Filename-2014.12.13-21.40.55
Version information is distinctly different from Date or Time stamping in that it has embedded major and minor revision information, not just the chronology information. Correct Version notation is intended for content under strict revision control, such as the Company Standards and Procedures Document, Client Contracts and Agreements, or Client-facing detailed Checklists.
Version Notation should not be used for fast-changing content as it would be cumbersome to maintain and you would likely find yourself at version 1,000,00.1 in a very short time.
While Version Notation can, as a general rule, contain or include any part of a Date Stamp or Time Stamp, it should be derived relative to the maturity of the content being tracked. To state it another way, a good Version notation should clearly indicate the maturity of the service or product in a simple way. Conversely, sometimes the Date or Time Stamp is the best measure of the maturity or the state of a given thing. The use of Date and Time Stamps is called out below to allow for cases where it will be used in a Version Notation.
Version information can be embedded in the name of the document or it can be inside the document.
All version information entries should follow the guidelines detailed below.
• The Scale for the Version Notation for a given document, service, process, product, etc. must be called out and documented somewhere if it is not obviously tied to a Date or Time Stamp.
• The documentation of the Scale for the Version Notation of a given thing may be in any of the following locations:
In the actual document itself
In a readme.txt file in the document folder (or with the file group)
In a Standards and Procedures document
In a wiki page, forum entry, or other such collaboration site element
• Numbered Version hierarchy should always be separated by a period.
e.g. Where the major version is 3 and minor version is 0 (zero) => Version 3.0
• Mixed metadata Version hierarchy may use a dash “-” with or without spaces.
E.g. Where the major version is 3 and minor version is Revision 4
=> Version 3 – Revision 4
• Where possible and reasonable, the Version field should be denoted by one of these three nomenclatures:
The word: Version – e.g. Version 3.0
The abbreviation: Ver. – e.g. Ver. 3.0
The letter or entry: V. (Capital letter V with a single period.) – E.g. V. 3.0
• Any words used in the Version Notation may be abbreviated in any fashion desired.
E.g. Version 3 – Revision 3 => Ver. 3 – Rev. 4, V.3 – R4, etc.
• The Version metadata should be a simple-to-follow system, such as:
Major Version + Minor Version (Preferred)
Numbers + Letters
Date + Time
Date + Number
Other logical combinations
• Unless absolutely necessary, the Version Notation should not be excessive or confusing in that it uses more than two nomenclatures.
I.e. Date + Time + Letter, as in: Version 2014.12.13.21.40a
Date + Major Version + Minor Version, as in: Version 2014.12.13.3.0
• When a Version is embedded into a filename, it should be stripped down following the steps below:
Note: The only required step is the first one, removal of spaces. All other steps may be skipped.
1) Remove all spaces
E.g. Version 3.0 Rev. 4 => Version3.0Rev.4
2) Separate metadata using the most appropriate character (typically a period or dash) if there is any chance of confusion or ambiguity, or if it is simply desired for aesthetics.
e.g. Version3.0Rev.4 => Version3.0-Rev.4
3) Abbreviate any wording desired (try to keep it human understandable).
e.g. Ver.3.0-Rev.4 or V3.0-R4, etc.
• When entering a Version Notation into a document, it should be:
◦ Placed on the earliest possible relevant page of the document. I.e. Not on the company logo page, but on the Table of Contents Page or the Title page.
◦ Placed on the topmost line on the right side of the page. See the Version Notation of this document for an example.
• When referring to a Version Notation in writings, it should never be abbreviated or stripped down to avoid confusion or misunderstandings, or ambiguity.
Adding Date Stamps or Time Stamps
• Refer to the Date Stamp and Time Stamp sections above for specific rules about those Stamps.
Last Update: November 27, 2018
Tell us how can we improve this post?
Log In is required for submitting new question.