Seems Time::Zone was never adjusted in 2011, so it already has the new value.

"msk" => +3*3600, # Moscow
[download]

I don't know why you'd ever want to use Time::Zone. In addition to the module's lack of any ability to handle changes, those three letter time zones are not unique.

Note that the latest DateTime::TimeZone (used by DateTime) is already aware of the upcoming changes to Europe/Moscow.

    ...
    [
63436863600, #    utc_start 2011-03-26 23:00:00 (Sat)
63549957600, #      utc_end 2014-10-25 22:00:00 (Sat)
63436878000, #  local_start 2011-03-27 03:00:00 (Sun)
63549972000, #    local_end 2014-10-26 02:00:00 (Sun)
14400,
0,
'MSK',
    ],
    [
63549957600, #    utc_start 2014-10-25 22:00:00 (Sat)
DateTime::TimeZone::INFINITY, #      utc_end
63549968400, #  local_start 2014-10-26 01:00:00 (Sun)
DateTime::TimeZone::INFINITY, #    local_end
10800,
0,
'MSK',
    ],
[download]

14400 = 4*3600, 10800 = 3*3600.

use DateTime::Format::RFC3339 qw( );

my $f = DateTime::Format::RFC3339->new();
say $_->set_time_zone('Europe/Moscow')->hms()
   for
      $f->parse_datetime('2014-09-01T12:00:00Z'),
      $f->parse_datetime('2015-09-01T12:00:00Z');
[download]

16:00:00
15:00:00
[download]

Barring that, I'd recommend contacting the maintainer of Time::Zone directly.

it superficially appears to me that Time::Zone contains hard-coded time-zone offsets, which is probably not a sound algorithmic approach.   Whereas DateTime::TimeZone appears to make use of .tzinfo files, which (at least on Un*x-ish systems) is the standard approach that is used by “the operating-system in general.”   Therefore, I have high confidence that .tzinfo files will be available that know about this change, whereas for the other Perl module it’s anybody’s guess.   I think that there ought to be “one source of Truth,” which in this case would be .tzinfo files.   Therefore, of the two approaches, I would favor the latter.   (Disclaimer:   I have not looked into the issue closely, and don’t plan to ...)