Perl 5.43.7 repairs daylight-saving time formatting

Perl 5.43.7, released on January 19 according to the interpreter history, fixes a daylight-saving regression introduced in 5.42.0. The versioned release notes identify an error that can put the time or timezone an hour out around a transition. They locate the visible Perl interface in POSIX::strftime and also name the affected C interfaces used by XS extensions. That makes the formatting operation a useful place to begin an investigation when a timestamp appears to have changed.

I still choose Perl for one-off text work, including restructuring a large log file. After nearly thirty years with it, I care about the assumptions hidden inside an otherwise convenient expression. A timestamp transformation can look like routine text processing while depending on calendar conversion and timezone interpretation. I would treat this release as a reason to inspect those dependencies in any script that formats local times.

The error occurs at a representation boundary

A time value and a string displaying that time serve different purposes. The localtime documentation for this release describes conversion into nine calendar fields for the local timezone. Those fields include a daylight-saving indicator. A formatter receives calendar information and produces the representation that a person or another program sees. An error there can make correct input appear to refer to a different hour.

The release notes specify intervals surrounding transitions to and from daylight-saving time. They do not say that every timestamp is affected. I would therefore avoid diagnosing this through a sample taken at an arbitrary midday. A test needs inputs on both sides of the relevant transition, with expected results established independently of the interpreter under test. Reformatting the current time successfully provides little evidence about this particular defect.

This distinction also limits what I would infer from an incorrect log line. A wrong displayed hour does not by itself establish that the stored time value is wrong. Before changing a parser or adding an offset, I would retain the original value and compare the intermediate calendar fields with the final formatted string. Otherwise, a workaround could modify valid input to compensate for a defect later in the transformation.

The POSIX documentation in the release source documents the formatter and its arguments. It also states that its weekday and day-of-year arguments are ignored because the other fields determine them. This is another reason to regard formatting as an operation with semantics of its own. Passing an existing calendar tuple does not mean every supplied field controls the result directly.

A small probe needs an independent expectation

The following program accepts an existing time value and prints both the local calendar fields and their formatted representation. It is an inspection aid, not a reproducer that claims to trigger the regression on every machine. Run it with a deliberately selected value and the timezone environment relevant to the application.

use strict;
use warnings;
use POSIX qw(strftime);

my $epoch = shift @ARGV;
die "supply a time value\n" unless defined $epoch;
my @local = localtime($epoch);
print "input=$epoch\n";
print "calendar=", join(",", @local), "\n";
print strftime("%Y-%m-%d %H:%M:%S", @local), "\n";

The explicit import keeps the example limited to the formatter. The release source recommends specifying POSIX imports because the default imports a large collection of symbols. For a diagnostic script, keeping the imported operation visible also makes it easier to see which part of the program needs comparison across interpreter versions.

I would preserve the expected calendar fields and formatted output in a regression fixture. The expectation should state which timezone it assumes. A fixture whose expected output is generated by the same formatting call cannot detect a disagreement between intended behavior and the implementation. It only records whatever the current interpreter happens to produce.

For a production decision, I would also distinguish the development interpreter from the supported interpreter being deployed. The versioned documentation labels 5.43.7 a development release. Its fix establishes progress in that development line. It does not establish that an installed maintenance package contains the change. An operator needs the package supplier or branch documentation to answer that separate question.

Native extensions need the same scrutiny

The release notes also identify my_strftime, sv_strftime_ints, and sv_strftime_tm as affected interfaces in XS code. A search limited to Perl files containing POSIX::strftime can therefore miss another route to the defect. If a module formats dates through native code, I would inspect that module before declaring the application unaffected.

This is a useful example of why a runtime upgrade needs tests at the application boundary. A direct formatter test can establish what the interpreter does for selected inputs. A test of the final exported record establishes whether the application reaches that formatter and preserves its output correctly. Both questions matter when formatted times become input to another system.

There is also a separate parser repair in this release. The notes describe hexadecimal floating-point literals whose significands exceed the unsigned integer range used during parsing. The examples distinguish the relevant limits on platforms with different integer widths. I would keep that issue separate from the time regression when planning tests, since a successful calendar fixture says nothing about literal parsing.

My immediate priority would be a transition-specific fixture for any Perl transformation that emits local calendar times. The fixture should preserve the input value, timezone assumption, and expected formatted result together. That gives a future interpreter or packaging change a concrete behavior to verify, including when the formatting call is hidden inside an extension.