Assigning a consistent timestamp to each line/message #742

New Issue

2026-10-05T04:42:07+02:00

adam commented

2026-10-05 04:42:07 +02:00

From https://github.com/jpnurmi/znc-clientbuffer/pull/7#issuecomment-266006958:

Each message/line in ZNC, from beginning to end, should have a single timestamp associated with it and accessible from within modules. /cc @psychon

Sounds like a good idea. An implementation idea would be to add this to CMessage. If I understand this right, every IRC-line that ZNC parses ends up as an instance of someting inheriting from CMessage, so if CMessage took a timestamp e.g. when it is constructed, everything would have access to a consistent timestamp.

Good reason from therein:

So there’s this one slight issue left… When using znc.in/self-message capability, after reconnecting, my own last message is sent back to me. But only to the client that actually sent it, others work okay.
[…]
My first guess would be that sending a message from a client (identifier) does not update its seen timestamp. This would cause the issue.
[…]
Oh, it seems like it’s more complicated. So the timestamp of me sending the PRIVMSG is indeed updated. But the timestamp of this entry in the buffer is slightly off. 300 µs in my case.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/39964770-assigning-a-consistent-timestamp-to-each-line-message?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

From https://github.com/jpnurmi/znc-clientbuffer/pull/7#issuecomment-266006958: >> Each message/line in ZNC, from beginning to end, should have a single timestamp associated with it and accessible from within modules. /cc @psychon > > Sounds like a good idea. An implementation idea would be to add this to `CMessage`. If I understand this right, every IRC-line that ZNC parses ends up as an instance of someting inheriting from `CMessage`, so if `CMessage` took a timestamp e.g. when it is constructed, everything would have access to a consistent timestamp. Good reason from therein: > So there’s this one slight issue left… When using `znc.in/self-message` capability, after reconnecting, my own last message is sent back to me. But only to the client that actually sent it, others work okay. > […] > My first guess would be that sending a message from a client (identifier) does not update its seen timestamp. This would cause the issue. > […] > Oh, it seems like it’s more complicated. So the timestamp of me sending the PRIVMSG is indeed updated. But the timestamp of this entry in the buffer is slightly off. 300 µs in my case. <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/39964770-assigning-a-consistent-timestamp-to-each-line-message?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:42:08 +02:00

Will a fix for this close the issue that started the referenced PR? (Also the issue message markdown seems broken.)

Will a fix for this close the issue that started the referenced PR? (Also the issue message markdown seems broken.)

adam commented

2026-10-05 04:42:09 +02:00

Daniel, not directly, but having one consistent timestamp for each message
in ZNC, will free clientbuffer from calling gettimeofday (for each
message), which returns logically incorrect values, leading to inconsistent
and unexpected behavior.

Also, the module hooks would need to get this timestamp somehow. IIRC (I'm
not at the computer right now), now the modules are getting just CStrings.
Arguably, stringly-typed programming is not one that should be practiced. =P

The fix for clientbuffer would involve changing gettimeofday to this new
per-message timestamp. Probably +3-3 diff or similar.

Thank you for taking interest in this!

Daniel, not directly, but having one consistent timestamp for each message in ZNC, will free clientbuffer from calling `gettimeofday` (for each message), which returns logically incorrect values, leading to inconsistent and unexpected behavior. Also, the module hooks would need to get this timestamp somehow. IIRC (I'm not at the computer right now), now the modules are getting just CStrings. Arguably, stringly-typed programming is not one that should be practiced. =P The fix for clientbuffer would involve changing `gettimeofday` to this new per-message timestamp. Probably +3-3 diff or similar. Thank you for taking interest in this!

adam commented

2026-10-05 04:42:10 +02:00

Also, the module hooks would need to get this timestamp somehow. IIRC (I'm not at the computer right now), now the modules are getting just CStrings.

Not really. The module API was changed (well, replaced) and the CStrings-based one is marked as deprecated. The new one gets instances of CMessage, so if timestamps are added to CMessage, modules would automatically have access to them.
For example: https://github.com/znc/znc/blob/master/include/znc/Modules.h#L693-L699

> Also, the module hooks would need to get this timestamp somehow. IIRC (I'm not at the computer right now), now the modules are getting just CStrings. Not really. The module API was changed (well, replaced) and the CStrings-based one is marked as deprecated. The new one gets instances of CMessage, so if timestamps are added to CMessage, modules would automatically have access to them. For example: https://github.com/znc/znc/blob/master/include/znc/Modules.h#L693-L699

adam commented

2026-10-05 04:42:10 +02:00

@psychon, ah! Great to hear that, then. 😸

@psychon, ah! Great to hear that, then. :smile_cat:

adam commented

2026-10-05 04:42:11 +02:00

So after each CMessage gets a timestamp during its creation, I’d argue that no other place should ask the kernel for time, to keep everything consistent. And most of all, timestamps in replay buffers should be equal to timestamps of corresponding CMessages.

So after each `CMessage` gets a timestamp during its creation, I’d argue that no other place should ask the kernel for time, to keep everything consistent. And most of all, timestamps in *replay buffers* should be equal to timestamps of corresponding `CMessage`s.

adam commented

2026-10-05 04:42:12 +02:00

Uhm. CMessage instances already have a timestamp accessible via GetTime:
https://github.com/znc/znc/blob/384681351228c1a4e4be2bea3d7ae7585409a210/include/znc/Message.h#L102

This is either the time when the CMessage instance was created or the time-tag that the server sent.

Uhm. CMessage instances already have a timestamp accessible via GetTime: https://github.com/znc/znc/blob/384681351228c1a4e4be2bea3d7ae7585409a210/include/znc/Message.h#L102 This is either the time when the CMessage instance was created or the `time`-tag that the server sent.

adam commented

2026-10-05 04:42:12 +02:00

Awesome, so we’re waiting impatiently for a stable 1.7.x. =)

I’ve looked through the code and it seems that after creation, the timestamps are not update. Exactly what we needed!

Awesome, so we’re waiting impatiently for a stable `1.7.x`. =) I’ve looked through the code and it seems that after creation, the timestamps are not update. Exactly what we needed!

adam commented

2026-10-05 04:42:13 +02:00

I'm not entirely sure what znc-clientbuffer would do with a timestamp coming from the server, by the way. They might cause some kinds of breakage if the clocks aren't syncronized and timestamps start going backwards...

I'm not entirely sure what znc-clientbuffer would do with a timestamp coming from the server, by the way. They might cause some kinds of breakage if the clocks aren't syncronized and timestamps start going backwards...

adam commented

2026-10-05 04:42:14 +02:00

@psychon, sigh, right… 😞 Well, let’s then reopen this and gather more opinions.

@psychon, *sigh*, right… :disappointed: Well, let’s then reopen this and gather more opinions.

adam commented

2026-10-05 04:42:14 +02:00

FYI, my fork of the ClientBuffer module (which now serves as the project's main repository, as @jpnurmi has been MIA) uses the new ZNC 1.7.x API when built against ZNC 1.7.x. I believe it works perfectly, other than some possible rare hickups when replaying self-messages - still need to track this down, but by the sound of it, certainly sounds plausible that it could be caused by a mismatch between local and server timestamps (self-messages' timestamps would need to come from local time, whereas received ones would have the server timestamp if any).

FYI, [my fork of the ClientBuffer module](https://github.com/CyberShadow/znc-clientbuffer) (which now serves as the project's main repository, as @jpnurmi has been MIA) [uses the new ZNC 1.7.x API when built against ZNC 1.7.x](https://github.com/jpnurmi/znc-clientbuffer/commit/38f51045d20729428e7ffa5b6345b9d4009af3b3). I believe it works perfectly, other than some possible rare hickups when replaying self-messages - still need to track this down, but by the sound of it, certainly sounds plausible that it could be caused by a mismatch between local and server timestamps (self-messages' timestamps would need to come from local time, whereas received ones would have the server timestamp if any).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#742