14 Jan
2017
14 Jan
'17
6:40 a.m.
On Fri, Jan 13, 2017, at 23:41, Nick Downing wrote:
I see, no I had not realized that code is still in
use, I would have
thought it had been replaced by a whole lot of POSIX bloat.
POSIX doesn't even have the timezone files - it 'allows' for
implementation-defined timezones, but POSIX itself basically only
defines the System V TZ variable with a few extra bits to specify a
single set of daylight saving rules, e.g. "EST5EDT,M3.2.0,M11.1.0".
Admittedly
the
2.11BSD ctime/asctime/localtime/timezone stuff is simplistic and doesn't
address complicated cases but it's good enough.
What's in 2.11BSD (and 4.3BSD) is essentially the 1987 mod.sources
version of Arthur David Olson's timezone code, compare e.g.
https://github.com/eggert/tz/blob/c07b3825e1ae6e9d077a1d97088b853a79237a01/…
to
http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/src/lib/libc/gen/ctime…
- it's basically the same except for a few ifdefs and the presence of
asctime in the same file. The code has obviously evolved a lot since
then, but the binary zone file format is the same (except for some
backwards-compatible additions).
The code in 2.9BSD and 4.1BSD is much more simplistic, hardcoding US
daylight saving rules rather than looking up the applicable offset for a
timestamp from a table. What's interesting is that 4.2BSD's is arguably
"smarter" in some ways than either, calculating daylight savings based
on rules at runtime whereas today that is the province of zic. This used
the timezone structure of gettimeofday.
However I have to resist the temptation to improve or
update stuff in
2.11BSD, I went down that path many times (with the Makefiles project for
instance) and because everything is interdependent you always introduce
more problems and get deeper and deeper enmeshed. In order to stay in
control I only fix essentials and apply a rule of minimal change, period.
This applies until I have a baseline that builds exactly the same binary
system image as the native build. Then I might proactively improve parts
of
the system but I will not do it reactively if you follow.
I guess I was considering my suggestion to be a "zic cross-compiler" -
which runs on the host system and is therefore not part of 2.11BSD
itself.