🚀 go-pugleaf

>I always thought the whole idea of the BSD way of determining the dst was
>extermely redundant

Try "The V7 way of determining..."; putting it into the kernel
antedates 4.2BSD.

>in contrast to the sysV method, in which anyone can choose whether to have
>it or not any time, in run time, per process run; on BSD systems it's a big
>and ugly routine, compiled into every utility,

Whereas on System V, it's *still* a big and ugly routine, compiled
into every utility - or, more to the point, it's a big and ugly
*table*, compiled into every utility, in most UNIX systems out there.
At least Berkeley made an attempt to put tables for areas other than
the US into those utilities (even though there were a number of
errors in the tables).

There *is* a solution; Arthur Olson came up with a version of "ctime"
and friends that reads the DST rules out of a *file*, which is where
they should have been in the first place.  If the rules change, you
just edit a file and compile it into a table; any programs run after
that point will have the correct rules.

The file to be read is selected by the TZ environment variable, so a
user *can* override the default setting if they want.  A program can
also *ignore* the value of TZ; this is required by programs such as
"uucico" that must know the time zone the phone lines are in, *not*
the time zone the user is in.  You can even arrange to give the files
names like EST5EDT, so that you can set TZ to values that will work
with binaries built on systems that don't have this new stuff;
solutions I've seen proposed that encode the rules in the TZ
environment string don't have this property, so they break binary
compatibility (not to mention breaking programs that expect to
convert dates not in the current year - remember, "last year" is, at
certain times, less than one day ago!).