Addition to Arthur Olsen/4.3bsd table-driven ctime
Mon Apr 6 08:11:07 UTC 1987
>> I cannot be sure that my customers will install the necessary
>> timezone support files.
> Neither can you be sure that they will install /etc/passwd. You don't
> handle that, why handle this?
/etc/passwd is standard on the systems I'm selling to;
/etc/zoneinfo isn't (yet). A customer doesn't have to install
/etc/passwd to get my software to run; I know he already has it,
or else he's got a broken system, and it's his problem, not mine.
>> I insist that both timezone and DST corrections be applied, even in
>> the absence of /etc/zoneinfo, which means that ctime must carry
>> some DST information along in its data segment, so it can perform
>> at least as well as it used to.
> This is unclear to me.
What I'm worried about here is systems that haven't applied any
fixes. I detest "two steps forward, one step back" improvements,
so I'm trying to arrange that a ctime that I link into my code
behave 100% backwards-compatibly when shipped to a site that
depends on using the old ctime.
By "backwards-compatibly," I mean that any new ctime, when
operating in an environment without /etc/zoneinfo, must generate
the same results as (i.e. localtime must be functionally
identical to) the "old" versions of ctime. If not, there will be
periods of time (such as the three-week period when lazy and/or
sensible systems simply set their clock ahead by an hour) during
which the new version of ctime will generate a different local
time value than the rest of the utilities on the system (date,
ls, anything linked with the old ctime) when presented with the
same kernel timestamp.
>> The next question is, should any DST information hard-compiled
>> into ctime be fixed to reflect recent changes? The surprising
>> answer is "no."
> That means that your worst case is off by an hour. (Ignoring double
> DST.) The same as 4.3's. What am I missing?
No. It's off by 0 hours, at all times of any past or present
year, when shipped to a system that applies no fixes. (Actually,
there is a worse worst case, that of the site that applies the
fixes in Article 13, to arrive at a temporarily fixed but still
non table-driven ctime. I can't arrange for things to work
correctly in this case without breaking things in the other two
cases, and I consider the other two cases -- the no fix case and
the Arthur Olsen case -- more likely.)
Actually, no one else here at Tektronix is at all concerned about
this issue, and the witching hour has come and gone, so it's
probably not worth our thrashing this out. I thought my
arguments were fairly convincing, and I tried to sweeten the pot
by offering working code, but I admit that these are pretty fine
points I'm considering, and since nobody else seems to be
interested, I think I'll drop the whole thing and go off and find
other damsels to rescue :-).
More information about the tz