You got me interested, so I played around with it and here’s what I’ve found:
It seems to take the same format as any other similar duration-related input I’ve encountered:
a raw number is interpreted as seconds
You can specify a number as another duration with tokens:
s = seconds (default)
m = minutes
h = hours
d = days
w = weeks
You can combine them in any order - whitespace is ignored: eg: “2s 2h 2w”
e.g.:
1w2d3h4m5s works
tokens can be in any order (5s4m3h2d1w also works)
Days and weeks just get added together. If you specify 1w8d, this is the same as 2w1d
The last value specified may be in h:m:s format or in h:m (omit seconds)
Interestingly, if you mix and match, they just get added:
“1d 2h 12:30” → “1d 14:30:00”
Values larger than 536870911 seconds are stored and tracked but when displayed show as 0sec.
(248 days, 13:13:55)
The maximum value is 4294967295 seconds (which is the maximum 32-bit value)
This decodes to: 7101w3d6h28m15s as the largest value…
(7101 weeks is ~136 years counting for leap years, by the way)
For me, “1d 00:00:00” works but “1w2d3h4m5s” and “1d 2h 12:30” don’t work in the winbox. OK in the CLI.
The correct syntax is not described in the wiki !
As this seems to be the only place dealing with details of address-list-timeout, I’m adding some observations here.
In my project I needed to monitor connected devices’ activity and take some action if it disappears. So I am using firewall filter rules adding the addresses of these devices to dedicated address lists with a timeout, and I am running a script every second which checks for existence of address list items and takes action based on their absence.
However, the items remain in the list for a couple of seconds (about 5) after their timeout value decreases to 0s. So the time needed to notice the disappearance of network activity of a device is those 5 seconds higher than expected.
This is true as of 6.42rc49 / March 2018, may change in future.