Skip to content
This repository has been archived by the owner on Jun 6, 2021. It is now read-only.

Bantracker duration parsing could be improved #22

Open
ilbelkyr opened this issue Jan 16, 2018 · 0 comments
Open

Bantracker duration parsing could be improved #22

ilbelkyr opened this issue Jan 16, 2018 · 0 comments

Comments

@ilbelkyr
Copy link

Currently, if an op sets a ban duration in a format eir doesn't recognize (e.g. ~1y thinking it will be a year-long ban), this will silently assume the ban to expire in just 1 (which is assumed to be minutes by default). It'd probably be more desirable to complain to the commenting op.

The relevant code is in sub calc_time:

eir/scripts/bantracker.pl

Lines 718 to 740 in 6a267fb

sub calc_time {
# take a dircbot style time specification
# and return a time in seconds
my $spec=shift @_;
my $time=0;
while ($spec =~ /^~?(\d+)([dhmsw]?)/) {
if ($2 eq 'm') {
$time+=$1*60;
} elsif ($2 eq 'h') {
$time+=$1*3600;
} elsif ($2 eq 'd') {
$time+=$1*86400;
} elsif ($2 eq 'w') {
$time+=$1*604800;
} elsif ($2 eq 's') {
$time+=$1;
} else {
$time+=$1*60;
}
$spec=$';
}
return $time;
}

Allowing 'y' to indicate years would only be a partial solution as eir would still accept other invalid inputs. While it could be argued that those are the commenting op's problem, I feel it'd be nicer to tell them what they're doing wrong in that case.

Side note: The regex used uses a \d character class. This probably ought to be [0-9] to avoid matching Unicode digits that aren't handled as numbers by Perl, such as ٧ (U+0667, ARABIC-INDIC DIGIT SEVEN). Alternatively, the /a modifier introduced in Perl 5.14 could be used.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant