I have occasionally had replies show before my messages, so I 
decided to look into it.   It looks like rcirc looks at the time 
of the message, compares it to the `rcirc-time' text property of 
other messages, and places it so that the property is properly 
ordered. 
 
> ============================= Disregard this, the patch does not 
> fix it.  I decided to keep it in because the problem is still 
> possible, but not it's not what's responsible for this specific 
> issue. 
The issue with this is, because the recieved messages' precision 
can be less than the sent messages' precision (`current-time' 
returns the time down to milliseconds but servers may choose to 
only keep it down to seconds), this causes some issues when a 
message is recieved after a message was sent but still within the 
same second. 
> ============================= 
 
An example of this, with the value of the text property 
`rcirc-time' at the left of the message itself, is: 
> (25469 29640 874652 270000)   > 02:13 <thuna`> ,ping
> (25469 29641)                 > 02:13 <fsbot> ␕
> (25469 29642 502966 649000)   > 02:13 <thuna`> ,ping
> (25469 29643)                 > 02:13 <fsbot> ␕
> (25469 29643 755653 540000)   > 02:13 <thuna`> ,ping
> (25469 29644)                 > 02:13 <fsbot> ␕
> (25469 29645)                 > 02:13 <fsbot> ␕
> (25469 29645 103860 988000)   > 02:13 <thuna`> ,ping

As you can see, the response to the last ping arrived after the ping
itself, but because of the precision difference, rcirc sorted the
messages wrong.

The issue was with `parse-time-string'.  It (and by proxy
`parse-iso8601-time-string'), uses `iso8601-parse' with nil FORM,
resulting in the subsecond precision being thrown out.  To fix this, I
added FORM arguments to those two functions as well.