Note that this approach will have a problem for those days with less than 24 hours

I would be interested to see a test case showing that, if you could provide one. The tests I tried all worked fine, even on 23-hour days. That's why I posted it as-is rather than trying to work around a problem which didn't appear to be there.

Here's my trivial test script for comparison:

use strict;
use warnings;

use Time::Piece;
use Test::More tests => 366 * 2 + 1;

my $dstr = '01/01/2023';

for (1 .. 366) {
    my $t = Time::Piece->strptime ($dstr, '%d/%m/%Y');
    my $nt = $t - 86400;
    isnt $dstr, $nt->dmy ('/');
    my $ddiff = $t->mday - $nt->mday;
    ok ($ddiff < 0 || $ddiff == 1), '1 day different or month wrap';
    $dstr = $nt->dmy ('/');
}
is $dstr, '31/12/2021';
[download]

This is because Time::Piece doesn't care as much about timezones and DST. When using DateTime (because I know it is exact with timezones, bordering on the unusable), in the following program, I can make things skip from 03/27/2023 to 03/25/2023:

use 5.020;
use Test2::V0;
use DateTime;
use DateTime::Format::Strptime;

my $dstr = '2023-03-27 00:30';
my $strp = DateTime::Format::Strptime->new(
    pattern   => '%Y-%m-%d %H:%M',
    locale    => 'de_DE',
    time_zone => 'Europe/Paris',
);

my $t = $strp->parse_datetime($dstr);
diag $t->strftime('%Y-%m-%d %H:%M %z');
my $nt = $t->clone->subtract( seconds => 24*60*60 );
isnt $t->ymd('-'), $nt->ymd('-');
diag $nt->strftime('%Y-%m-%d %H:%M %z');
my $ddiff = $t->mday - $nt->mday;
ok( ($ddiff < 0 || $ddiff == 1), '1 day different or month wrap');
$dstr = $nt->ymd ('-');
is $dstr, '2023-03-26';
[download]

Update: I just realized that your code doesn't care about the time, and it (implicitly) always is at 00:00. Adjusting my example from 00:30 to 00:00 shows the problem there:

use 5.020;
use Test2::V0;
use DateTime;
use DateTime::Format::Strptime;

my $dstr = '2023-03-27';
my $strp = DateTime::Format::Strptime->new(
    pattern   => '%Y-%m-%d',
    locale    => 'de_DE',
    time_zone => 'Europe/Paris',
);

my $t = $strp->parse_datetime($dstr);
diag $t->strftime('%Y-%m-%d %H:%M %z');
my $nt = $t->clone->subtract( seconds => 24*60*60 );
isnt $t->ymd('-'), $nt->ymd('-');
diag $nt->strftime('%Y-%m-%d %H:%M %z');
my $ddiff = $t->mday - $nt->mday;
ok( ($ddiff < 0 || $ddiff == 1), '1 day different or month wrap');
$dstr = $nt->ymd ('-');
is $dstr, '2023-03-26';
[download]

This is because Time::Piece doesn't care as much about timezones and DST.

Precisely so. That's another good reason to use it in this sort of scenario where DST is a hindrance at best. I don't see why, given a problem where DST and timezones would only complicate things, the user would choose a non-core module where these are important over a core module which for the most part ignores them.

For the general audience reading this, if you are used to DateTime or Date::Calc or any of the myriad other modules, I do recommend that you become at least passingly familiar with Time::Piece. It is pretty simple, fairly lightweight and core. It won't solve all problems but it handles a good subset of them, including the one in this thread, very well indeed.

---

🦛

If you want Time::Piece to respect time zones, you need to initialize the object from localtime, not from the class itself:

$ TZ=Europe/London perl -MTime::Piece -wE '
    for my $source ("Time::Piece", scalar localtime()) {
        my $t = $source->strptime("2023/03/27", "%Y/%m/%d");
        say $t - 86400;
    }'
Sun Mar 26 00:00:00 2023
Sat Mar 25 23:00:00 2023
[download]

Note that this approach will have a problem for those days with less than 24 hours

That's not true. Or rather, there are no days with less than 24 hours when dealing with UTC, as the parent code does.