4.5 timestamp

The transaction timestamp specifies a time window within which the occurrence of the transaction can be asserted. The reason for representing timestamps as windows is that, in distributed systems, there is no precise moment in time, but rather many unsynchronized clocks. This is due not only to physical laws but also to the nature of sharing transactions—especially if the transaction's signatures require multiple authorizations, the process of constructing a joint transaction could take hours or days.

It's important to note that the purpose of a transaction timestamp is to satisfy the logical imperatives of smart contract code and to communicate to the contract code the transaction's position on the time axis. Although the same timestamp might also be used for other purposes, like regulatory reporting or event sorting in user interfaces, there is no requirement to use timestamps in such ways. Sometimes, using locally observed timestamps, despite not precisely matching the times observed by other participants, might be a better choice. Alternatively, if a precise point on the timeline is needed and must be agreed upon by multiple participants, the midpoint of the time window can be used conventionally. Although this doesn't correspond precisely to any event (like a keystroke or verbal agreement), this method can still be useful.

Timestamp windows can be open, conveying that a transaction occurred before or after a specific time, but the exact duration isn't significant. The timestamp is checked by notary services. Since the participants in the notary service themselves do not have precisely synchronized clocks, whether a transaction submitted at the edge of a given time window is considered valid at the moment of submission is unpredictable. However, from other observers' perspectives, the signature of the notary service is decisive.

If a transaction has a signature from the notary service, it is assumed to have occurred within the given time. Note that the Java timeline used in Defimall represents time in UTC, with leap seconds included in the last 1000 seconds of a day, ensuring each day contains exactly 86400 seconds. Special attention is needed to ensure changes in the GPS leap second counter are correctly handled to maintain synchronization with Java time. When setting a transaction's time window, care must be taken to account for network propagation delays in the communication between users and notary services, and within the notary service itself.