bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place

[Philip Kaludercic]

Thuna <thuna.cing@gmail.com> writes:

> 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.

Sorry for missing this message, this patch looks like the right fix.  I
have recently been noticing issues related to this myself.

Would it be OK to apply this to emacs-29?