RFC 3161 Timestamps
A signature shows who signed a document and that it hasn't changed since, but not when it was signed. That gap matters years later, when the signer's certificate has expired or been revoked. A trusted timestamp from an RFC 3161 time server closes it: it certifies that the signature existed at a particular moment, while the certificate was still valid. TX Text Control requests the timestamp while it saves the signed PDF, so you only pass the address of a time server.
Getting Started adds a timestamp to a whole-document signature in Add a Trusted Timestamp. What a timestamp means for the profile of a signature is described in PAdES.
Why a Signature Needs a Trusted Time
Suppose a contract is signed in February 2026 with a certificate that expires in January 2027, and somebody checks the contract in 2032. At that point, a validator only knows that the certificate has expired, not whether it was valid in February 2026. Without a trusted time, validators such as Adobe Acrobat often show warnings or state that the long-term validity of the signature can't be verified, although the document is unchanged.
With a timestamp, the validator can answer all its questions: the signature matches the document, the timestamp is trusted, the certificate was valid at the time of the timestamp and the document hasn't changed since signing.

How a Timestamp Is Created
A time server, also called a Time-Stamping Authority (TSA), doesn't sign your document. When TX Text Control saves a signed PDF with a time server URL, these steps happen:
- TX Text Control creates the signature of the document.
- It sends a cryptographic hash of the signature to the time server. The PDF itself never leaves your system.
- The time server combines the hash with the current, trusted UTC time and signs the result with its own certificate.
- TX Text Control embeds the returned timestamp token in the PDF as part of the signature.
Because only a hash is sent, the time server has no access to the document or its content. Requesting a timestamp typically adds a fraction of a second to the signing process.
Specify the Time Server
Both constructors of DigitalSignature take the URL of the time server as their second parameter, timeServerURL:
Value of timeServerURL | Signing time |
|---|---|
null or an empty string | The current date and time of the computer |
The URL of an RFC 3161 time server, such as http://timestamp.digicert.com | A trusted timestamp from the time server |
Timestamps are offered by certificate authorities such as DigiCert, GlobalSign, Entrust and SSL.com, and many organizations operate their own time servers for internal signing workflows. Use a trusted server, because validators check the timestamp as well.
DigitalSignature has no further settings for the time server, such as credentials, a proxy or a timeout. The server is contacted when Save creates the PDF, not when the DigitalSignature object is created.
Add Timestamps to Signature Fields
When a document is signed in its signature fields, each field gets its own DigitalSignature in SaveSettings.SignatureFields, and each of them has its own time server URL. Pass the URL as the second constructor parameter in the loop of Sign the Fields of a Document, for example new DigitalSignature(certificate, "http://timestamp.digicert.com", field.Name). Sign Several Fields in One Save signs one field with a timestamp and the others without.
How Readers Show the Timestamp
In the Signatures panel of Adobe Acrobat Reader, a signature without a trusted timestamp is reported, once its certificate has expired, as a signature whose long-term validity can't be verified. For a signature with a timestamp, Acrobat Reader states that it includes an embedded timestamp:

The TXTextControl.PDF.Validation package reports the signing time that a signature contains, as Signature Validation describes.
Next Steps
- PAdES: the signature profiles with and without a timestamp.
- Signature Fields: sign visible signature fields.
- Certificate-Based Signatures: choose certificates that validators trust.