A week ago I was hit by a timestamp issue. I booted my computer and got online in a place with WiFi that allowed SSB but not NTP. I manually set my computer's clock (since it doesn't have a RTC). Turns out I set it wrong. I found this out after publishing a few SSB messages. I found it out when trying to log into a site with a TOTP. I set it to a more accurate time and then was going to publish an SSB message but the publish failed with Error: timestamp must be increasing. From sbot's perspective, I was trying to publish from the past. I could have set my clock back to the future and then published the message, or waited for my feed to catch up with the local time and then published the message, but did not have time to wait and did not want to use a "known incorrect" time, so instead I did not publish the message, and went on with my day. If I had accidentally set the time to a much more incorrect one, my feed could have been stuck in the future for an arbitrarily long time as @alanz cautioned in %GD42+sQ.... Maybe if peers rejected incoming future-dated messages then I could take the opportunity to fork my own feed back to the present - carefully and trustfully. Anyway, this is potentially a bad situation and indicates to me that concerns about the timestamp should be bubbled up into the UI - such as giving an indication in the composer of current times or time differences, such as from the local clock, last published message, last messages received from peers, or peers from RPC. The gossip.ping method can be used to ask peers for their time. That method was actually what I used to set my clock manually; next time maybe I will make a script to do it correctly.

Or, don't require peer's messages to have monotonically increasing timestamps.
If people engage in time travel, whether to recover from mistakes, or for other reasons, it is okay with me.

I see usefulness of socially-validated timestamps. For example, ranking algorithms like on reddit and HN use timestamps of submissions. But I'm not sure if this important enough to enforce as a network requirement in the replication layer. I would lean towards not requiring what is not necessary. But adding the time window exception for @elavoie would be better than the current behavior.