Lena manages contracts at a design studio in Geneva. On a Friday afternoon she seals a signed agreement, and the certificate shows the time as 15:40. A colleague in London opens the same certificate and reads 14:40. Both are looking at the same seal. Lena worries that one of them must be wrong, and that a client could use the gap to say the timestamp cannot be trusted. Neither time is wrong. They are the same moment shown on two clocks.
The short answer
A qualified timestamp records one exact moment on a shared world clock, and any local time you see is only that moment shown in your own zone.
The clock behind the seal does not run on Geneva time or London time. It runs on one agreed world time. When you or a court needs to compare two sealed files, you compare that shared time, not the local time on the screen. Think of it as one heartbeat that every local clock copies. Once you know this, two different local times stop being a problem. They point to the same instant, so the order of events is never in doubt.
What a time source is
A time source is the clock the seal trusts, and the law says that clock must follow one world standard.
For a qualified timestamp, eIDAS Regulation, Article 42(1)(b) says the time source must be "linked to Coordinated Universal Time (UTC)". UTC is the single reference time the whole world agrees on. It does not belong to any one country, and it does not shift with the seasons. This is the heart of a qualified timestamp UTC time source. The seal reads its moment from a clock tied to UTC, so the record does not depend on where the signer happened to be. A signer in Zurich and a signer in Singapore both land on the same kind of clock. That is what makes the record easy to trust and easy to compare later.
UTC versus local time
UTC is the one real moment in the record, and local time is only a friendly version of it for your screen.
Your country's local time is UTC plus or minus a set number of hours. Geneva in summer is UTC plus two hours. London in summer is UTC plus one hour. So a single stored moment can read as 15:40 on one screen and 14:40 on another. The seal keeps the UTC value. The local time you read is a display choice, not a second, separate time.
When two documents show different local times
If two sealed files show different clock times, convert both to UTC before you decide which came first.
Keep the explanation plain and true. Both files were sealed at moments recorded in UTC, and each screen showed that moment in its own zone. To put the files in order, read the UTC time on each certificate, not the local time. Daylight saving makes this matter even more, because the same country shifts by an hour twice a year. So two files from the same office, sealed a week apart, can show local times that look an hour off for no real reason. The UTC values will still line up. A careful file note should quote the UTC time first, then the local time in brackets if people find it helpful.
Why courts care
The law treats a qualified timestamp as accurate, so the exact UTC moment it records carries real weight in a dispute.
Under the eIDAS Regulation, Article 41(2), a qualified timestamp carries a presumption of the accuracy of the date and time it indicates. In plain words, a court starts from the position that the recorded time is correct, and the other side has to prove otherwise. That presumption rests on the time being tied to UTC. A clock that drifts or follows a local guess would not support it. This is why the shared world time, not the local display, is the part that counts.
How the seal records the moment
The seal sends only a fingerprint of your file to a trusted clock, which signs it together with the UTC time.
The method is a published standard called RFC 3161, the time-stamp protocol used for this kind of proof. Your file is not sent away. The platform makes a cryptographic hash, a short fingerprint of the file, and only that fingerprint goes to the timestamp authority. As our FAQ explains, the hash is signed together with a time from an audited clock. An audited clock is one that is checked on a schedule, so its time can be trusted. The result ties your exact file to one UTC moment, which anyone can later check through the public verification link without an account.
Back to Geneva
Lena writes one line in the file, and the worry is gone.
She notes that the agreement was sealed at a single UTC moment, shown as 15:40 in Geneva and 14:40 in London. The gap is just two clocks reading one instant. The clock behind the seal already did the hard part, because it was tied to UTC from the start.
Before you share a signed document, seal it so its moment is fixed on a clock the law trusts, then read the UTC time, not the local time, whenever you compare two files. You can start at swisstrustlayer.com.
