In the source to glibc's mktime you can find this:
/* tm.tm_isdst has the wrong value. Look for a neighboring
time with the right value, and use its UTC offset.
Heuristic: probe the adjacent timestamps in both directions,
looking for the desired isdst. This should work for all real
time zone histories in the tz database. */
/* Distance between probes when looking for a DST boundary. In
tzdata2003a, the shortest period of DST is 601200 seconds
(e.g., America/Recife starting 2000-10-08 01:00), and the
shortest period of non-DST surrounded by DST is 694800
seconds (Africa/Tunis starting 1943-04-17 01:00). Use the
minimum of these two values, so we don't miss these short
periods when probing. */
int stride = 601200;
/* The longest period of DST in tzdata2003a is 536454000 seconds
(e.g., America/Jujuy starting 1946-10-01 01:00). The longest
period of non-DST is much longer, but it makes no real sense
to search for more than a year of non-DST, so use the DST
max. */
int duration_max = 536454000;
/* Search in both directions, so the maximum distance is half
the duration; add the stride to avoid off-by-1 problems. */
int delta_bound = duration_max / 2 + stride;
If you do the math, you'll find delta_bound
is 268828200 seconds, equal to about 8 and a half years. It is almost exactly the difference between the zdump dates (in 1919 and 1942) and the times of your mysterious changeovers (in 1928 and 1933). Each one is off by exactly 25 hours 30 minutes. I haven't looked deeper to find the cause of that magic number.
Without understanding the whole thing, I think the comment basically means that when you're in the middle portion of that long non-DST stretch from 1919 to 1942, the algorithm tries to find a valid dst=1 timestamp near the one you supplied with the erroneous dst=1, and gives up before it finds one because it makes no real sense
. The years just outside that middle portion may not make much sense either, but behave differently as a side effect of that Jujuy-related tuning parameter.