Feature Request: Pass timestamp information as variable to scripts

[toushin-taishi]

As the title suggests, this will allow the BOT to use the actual date and time of the message as a variable, like how it was done in #18. This will provide matrix-eno-bot the ability to use scripts that need such information (e.g. logging function, Bundy clock scripts, etc).

Thanks in advance!

[8go]

Thanks @toushin-taishi for adding this feature request.

I guess we could add 2 new values, i.e. 2 new environment variables.

The incoming message, the message received by the bot, is an event. This event has the following fields:

{
  "type": "m.room.encrypted",
  "sender": "@bot:server.matrix.com",
  "content": {
    "algorithm": "m.megolm.v1.aes-sha2",
    ...
  },
  "origin_server_ts": 1622801592944,
  "unsigned": {
    "age": 6762151
  },
  ...
}

We could assign the value origin_server_ts from this event to environment variable ENO_TIMESTAMP_SENT.

And we could assign the current time (i.e. now) to environment variable ENO_TIMESTAMP_RECEIVED.

I would keep the time as-is in Unix epoch time.

Not relevant, but the above value of 1622801592944 in ENO_TIMESTAMP_SENT could be transformed by the invoked script/program to a human readable format, e.g. https://www.unixtimestamp.com/ tells me that this Unix epoch is equivalent to Fri Jun 04 2021 10:13:12 GMT+0000.) Anyway, I would leave everything in matrix-commander in Unix epoch, i.e. take the origin_server_ts value as is. It is up to the invoked script to convert it into a human readable format.

@troglodyne : Do you feel motivated to do this as well? Very similar to your previous PR (PR #21). I would guess adding these timestamps are about 3-5 lines of code. If you feel motivated please go ahead and submit another PR for this issue. The community will be thankful. :heart:

[troglodyne]

Yeah, should be fine to add this to ENV. I agree it would likely be a small change as well.

Can look at adding it later tonight, thanks

[8go]

Thanks @troglodyne for accepting. No hurry. Whenever it suits you.

[troglodyne]

Turns out origin_server_ts was a private property, the actual prop to access was server_timestamp. After that was a matter of dividing that by 1000 as it is milliseconds since the epoch.

Anyways, got a PR in for it now (#23)

Took me a bit longer than I thought, mostly due to having to account for whether or not you have set a server timezone other than UTC. In that case you'll want to ensure that the TZ env var is properly set for the daemon user, so I added the appropriate lines to the service file example.

Testing: I used a script called "timetest" which spit out formatted markdown:

#!/usr/bin/env perl
use strict;
use warnings;
use DateTime;

my ( $rcvd, $sent ) = map {
    my $prop = "ENO_TIMESTAMP_$_";
    die "Script requires $prop set in environment!" if !$ENV{$prop};
    DateTime->from_epoch( epoch => $ENV{$prop} )->strftime("%T %Z");
} qw{RECEIVED SENT};
my $interval = $ENV{'ENO_TIMESTAMP_RECEIVED'} - $ENV{'ENO_TIMESTAMP_SENT'};
my $msg = "__Message received at__: $rcvd\n\n";
$msg .= "__Message sent at__: $sent\n\n";
$msg .= "__Interval (in seconds)__: $interval\n";
print $msg;

0;

apt install libdatetime-perl if you don't have DateTime installed

Test results for me:

[toushin-taishi]

hi @troglodyne,

Thanks for this! Just want to say I tested your changes and found everything is working as intended.

[8go]

@troglodyne and @toushin-taishi : Thanks also from my part :+1:

Merged PR today, closing Feature Request.