I would appreciate your help in correcting my error. I am also curious as to what happens with these ambiguous local times, like in the US 1:23 AM can occur twice during the same day. Almost all my work is in GMT/UTC so I don't often work with local time myself.

use strict;
use warnings;
use 5.010;
use DateTime;
use DateTime::Format::Strptime;
$|=1;

my $str = 'Wed, 13 Jan 2021 17:22:23';
my $pattern = '%a, %d %b %Y %T';
my $strp = DateTime::Format::Strptime->new(
       pattern  => $pattern,
       time_zone => 'CST',
       zone_map => { CST => '-0700', EST => '-0600' }
       );
say "I got this far (not!)";       
my $dt = $strp->parse_datetime( $str );       
say "String:   $str";
say "DateTime: $dt";
say '';      
      
__END__
Invalid offset: CST
[download]

I am also curious as to what happens with these ambiguous local times, like in the US 1:23 AM can occur twice during the same day.

What...? Anyway, see the %p and %P tokens.

Invalid offset: CST

As per DateTime::Format::Strptime: "By default, the parser will die when it parses an ambiguous abbreviation."

$ perl -wMstrict -MDateTime -le 'print DateTime->now(time_zone=>$_)->s
+trftime("%Z %z") for qw# America/Havana Asia/Shanghai America/Chicago
+ #'
CST -0500
CST +0800
CST -0600
[download]

See also List of time zone abbreviations, ISO8601 Time zone designators, and Names of time zones.

Also occasionally a specific location can change its time zone - the International Date Line was moved some years back - this affected some islands in the Pacific.

Hence the existence of location-based time zone names that are unambiguous in that respect.

$ perl -wMstrict -MDateTime -le 'print DateTime->new(year=>$_,time_zon
+e=>"Pacific/Apia")->strftime("%Y %z") for qw/ 2010 2012 /'
2010 -1100
2012 +1400
[download]

What...?

Daylight Saving.

---

🦛

I guess that what this nets out to, is that if you log a "local time", you also need the time_zone.

I am in the US Pacific Time Zone (PST).
Once per year, a "day" will have 25 hours.
My wristwatch will wind up showing 1:15 AM twice during that day.
It is Ok that 1:15 AM PST and 1:15 AM PDST converts to a different GMT time,
but the time zone matters.

I recommend converting all times to GMT/UTC within the DB.

It's too late to be poking at things but I think the problem is that the argument validation is trying to coerce "CST" into a DateTime::TimeZone before it's done anything to do looking at your mapping. I think what that argument is for is providing a mapping for zones if they're named in the date which is being parsed. Tweaking your code slightly:

#!/usr/bin/env perl
use strict;
use warnings;
use 5.010;
use DateTime;
use DateTime::Format::Strptime;
$|=1;

my $str = 'Wed, 13 Jan 2021 17:22:23 CST';
my $pattern = '%a, %d %b %Y %T %Z';
my $strp = DateTime::Format::Strptime->new(
       pattern  => $pattern,
       zone_map => { CST => '-0700', EST => '-0600' }
       );
say "I got this far (not!)";
my $dt = $strp->parse_datetime( $str );
say "String:   $str";
say "DateTime: $dt";
say "zone: ", $dt->time_zone->name;
say '';

__END__
$ perl tz_thing.plx
I got this far (not!)
String:   Wed, 13 Jan 2021 17:22:23 CST
DateTime: 2021-01-13T17:22:23
zone: -0700
[download]

The cake is a lie.
The cake is a lie.
The cake is a lie.

I think what that argument is for is providing a mapping for zones if they're named in the date which is being parsed.

Yes, I agree, time_zone makes sense when the string being parsed doesn't contain a time zone specification, and zone_map makes sense when it does contain a time zone specification.

Your code works on my machine. Thanks!

Evidently CST is ambiguous because there is a China Time Zone.
zone_map{} appears to be necessary.