In a timely coincidence, today my Android phone informs me that new TZ / DST definitions have been uploaded and I need to restart the device for them to take effect.
This seems to happen at least two, and more usually 4 times per year, although not on any sort of organized schedule I can discern.
Everything related to time is complicated at the level of accuracy needed for software. This video is basically a 10 minute rant about that (actually 9 minutes if you’re crossing a timezone during a leap second on the lunar calendar 
).
Anyway, the point is, most developers don’t code this themselves, they rely on the OS or a separate library. Unless the app itself is heavily oriented around time or calendar functionality, in which case they have no choice but to get their hands dirty, and probably would need to patch the app if the DST rules change.
An example of the arcana that Paul Eggert captures in his time zone library…
http://mm.icann.org/pipermail/tz-announce/2022-November/000076.html
Zod bless him… someone cares that their program reflects the proper timestamp for Whitehorse in 1966.
Changes for pre-1996 northern Canada (thanks to Chris Walton):
Merge America/Iqaluit and America/Pangnirtung into the former,
with a backward compatibility link for the latter name.
There is no good evidence the two locations differ since 1970.
This change affects pre-1996 America/Pangnirtung timestamps.
Cambridge Bay, Inuvik, Iqaluit, Rankin Inlet, Resolute and
Yellowknife did not observe DST in 1965, and did observe DST
from 1972 through 1979.
Whitehorse moved from -09 to -08 on 1966-02-27, not 1967-05-28.
Colombia's 1993 fallback was 02-06 24:00, not 04-04 00:00.
(Thanks to Alois Treindl.)
Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time),
not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.)