Today I had big confusions with what turned out to be MC term's own logic to handle differences between message timestamps and system clock:
I did manually change the clock, wrote to a local "ping" channel, and the reply was also with the wrong, changed timestamp -- making us think that my wrong timestamp did change the clock of the companion which answers to the ping.
A lot of testing later revealed likely the following behaviour:
If the message's timestamp and system time are off by several hours only (20h still within the range, 24h outside the range), MC term uses the system time to display the message.
If the message's timestamp is differing from the system time by more, then the system time is set to the message's timestamp and that time is used to display the message.
Is this a feature to be robust to message timestamps that are incorrect? It was very confusing, though.
To make it easier to see what is going on, I hereby suggest that in the message's details both are displayed: Message timestamp (sent: <date>-<time>) and system time (received: <date>-<time>). (Setting the system time by message time has already been addressed in #213.)
Regards!
Today I had big confusions with what turned out to be MC term's own logic to handle differences between message timestamps and system clock:
I did manually change the clock, wrote to a local "ping" channel, and the reply was also with the wrong, changed timestamp -- making us think that my wrong timestamp did change the clock of the companion which answers to the ping.
A lot of testing later revealed likely the following behaviour:
* If the message's timestamp and system time are off by several hours only (20h still within the range, 24h outside the range), MC term uses the system time to display the message.
* If the message's timestamp is differing from the system time by more, then the system time is set to the message's timestamp and that time is used to display the message.
Is this a feature to be robust to message timestamps that are incorrect? It was very confusing, though.
To make it easier to see what is going on, I hereby suggest that in the message's details _both_ are displayed: Message timestamp (`sent: <date>-<time>`) _and_ system time (`received: <date>-<time>`).
*(Setting the system time by message time has already been addressed in #213.)*
Regards!
<!-- github-sync-id:4361438822 -->
Message detail / Sent timestamp: add a "Sent:" line to the message detail view showing the sender's embedded timestamp alongside the existing "Received:" line (device time when the packet arrived), for both the on-device UI and the WebUI. Allows users to compare the sender's claimed send time against the local receive time and diagnose clock discrepancies (#243).
### Fixed/Improved (v0.9.12.1)
- Message detail / Sent timestamp: add a "Sent:" line to the message detail view showing the sender's embedded timestamp alongside the existing "Received:" line (device time when the packet arrived), for both the on-device UI and the WebUI. Allows users to compare the sender's claimed send time against the local receive time and diagnose clock discrepancies (#243).
<!-- github-comment-id:4401649735 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Today I had big confusions with what turned out to be MC term's own logic to handle differences between message timestamps and system clock:
I did manually change the clock, wrote to a local "ping" channel, and the reply was also with the wrong, changed timestamp -- making us think that my wrong timestamp did change the clock of the companion which answers to the ping.
A lot of testing later revealed likely the following behaviour:
Is this a feature to be robust to message timestamps that are incorrect? It was very confusing, though.
To make it easier to see what is going on, I hereby suggest that in the message's details both are displayed: Message timestamp (
sent: <date>-<time>) and system time (received: <date>-<time>).(Setting the system time by message time has already been addressed in #213.)
Regards!
Fixed/Improved (v0.9.12.1)