Clients indicate support for the extension by requesting a capability server-time as per the IRC Client Capabilities Extension.
CAP REQ :server-time
After requesting the capability, clients MUST be able to parse an optional timestamp at the start of each message. The message pseudo-BNF, as defined in RFC 1459, section 2.3.1 is extended to look as follows:
<message> ::= ['@' <line-props> <SPACE>] [':' <prefix> <SPACE> ] <command> <params> <crlf>
<line-props> ::= <line-prop> [',' <line-prop>]*
<line-prop> ::= <key> '=' <value>
<key> ::= 't'
<value> ::= <time>
<time> ::= <A sequence of digits representing a Unix timestamp>
If the timestamp is presented, client SHOULD treat the message as the one happened at the given time instead of now.
The timestamp is a Unix timestamp specifying the seconds since the epoch (1970-01-01 00:00:00 +0000 UTC), as specified by POSIX.1. As explained there, this is NOT the actual number of seconds since that time since e.g. leap seconds are ignored and simplified rules for leap years are used. See POSIX.1 Annex B 2.2.2.
Servers MAY include the timestamp in messages when they see fit (in order to tell the client that the message really happened at the given time instead of now), but MUST NOT do so before acknowledging the client capability using CAP ACK. Clients MAY choose to simplify parsing by accepting timestamps at any point in the connection (e.g. even before CAP REQ).
Clients MUST NOT send timestamps, and a server receiving a message including a timestamp from a client SHOULD treat it as a protocol error.
Because the timestamp is optional, backwards compatibility with unsupporting servers is guaranteed. For example, the following message valid in RFC 1459 is still valid with the protocol extension:
:Angel PRIVMSG Wiz :Hello
If the server were to add a timestamp to this message, it would look as follows:
@t=1319042451 :Angel PRIVMSG Wiz :Hello