I believe you are being bitten by regex engine leaks.

Here's what I discovered.

1. If I replace _iso8601rx() with the bare minimum to parse the date/time in the test, the memory leaks disappear completely.

   my %cache;
   sub _iso8601_rx {
      my($self,$rx) = @_;
      my $dmt       = $$self{'tz'};
      my $dmb       = $$dmt{'base'};
   
      return $cache{ $rx } if exists $cache{ $rx };
   }
   
   $cache{cdate} = '(?<y>\d\d\d\d)-(?<m>\d\d)-(?<d>\d\d)';
   $cache{ctime} = '(?<h>\d\d):(?<mn>\d\d):(?<s>\d\d)';
   $cache{fulldate} = "$cache{cdate}\\s+$cache{ctime}";
   
   1;
   [download]

2. However, if I change that to using the fully expanded regexes, it goes back to leaking like a sieve:
   <Reveal this spoiler or all in this thread>

I thought that it was maybe the use of (so many) named captures, but I tried very hard to make them leak. A single regex with 175,000 named captures; matching /g against a string that contained 10,000 matches for them; in a (v.slow) loop. It grew very arge, but once it maxed out, it didn't leak at all.

So then I remembered that I'd seen the regex trie optimisation caused problems with large alternations, but disabling it didn't change things.

Then I thought to try your monster regexes in a standalone script and run them directly on the sample date in a loop:

#! perl 
use strict;
my %cache = ( ctime => <<'RXA', cdtate => <<'RXB', fulldate -> <<'RXC'
+ );

##... monster regex initialisation ellided;

my $refull  = qr[$cache{ fulldate }]x;
my $rectime = qr[$cache{ ctime }]x;
my $recdate = qr[$cache{ cdate }]x;

for (1..100e6) {
    "2010-02-01 01:02:03" =~ $refull;
    "2010-02-01 01:02:03" =~ $rectime;
    "2010-02-01 01:02:03" =~ $recdate;
}
[download]

it doesn't leak at all. Not a jot.

So, it's not just the monster regexes, but also how they're are being used, or the results are being used that triggers the leak.

I'm kinda stuck for a direction in which to go now, but I hope that this will help you zero in on the cause. I'll keep looking.