[tz] Java & Rearguard

[Paul Eggert]

On 6/3/19 9:44 AM, Fred Gleason wrote:
> I find it significant that POSIX apparently ended up ditching an entire
> API element in favor of adding a model capabale of handling the full
> complexities of civil timekeeping (as they were understood at the
> time); a move which surely must have caused heartburn for many POSIX-
> based applications in use at that time.

I suppose it must have caused some problems, although the applications 
world was smaller then. I don't recall any problems being publicized.

The precise road to the current spec for POSIX TZ strings is a bit 
obscure to me. I vaguely recall that in 7th Edition Unix the time zone 
was a kernel setting (and perhaps you had to rebuild the kernel?); 
presumably this inspired the gettimeofday API you mention, which was 
introduced some time between 4BSD (1980-10) and  4.1cBSD (1982-12), and 
was declared obsolete sometime between 4.3BSD Reno (1990-06) and 4.4BSD 
(1993-06); presumably Linux (released before 4.4BSD came out) picked up 
the API from 4.3BSD.

At some point the time zone was put into the user environment via the TZ 
variable, but only the forms TZ=XXXn and TZ-XXXnYYY were supported, with 
US daylight-saving rules being hardcoded in the C library; I don't know 
when and where this was first done, but it made the kernel setting (and 
thus the 2nd argument of gettimeofday) obsolete. However, this didn't 
work for non-US rules and vendors had nonportable ways to address this. 
In July 1986 the US changed its daylight-saving rules (effective April 
1987) and by then it surely had became clear to everybody that something 
better had to be done. The POSIX committee settled on something close to 
the current TZ design in the first POSIX edition in 1988, where they 
purposely did not standardize gettimeofday and suggested that something 
would be standardized later; by the time gettimeofday made it into POSIX 
its timezone argument was completely vestigial.

It's possible the POSIX TZ design was a committee invention, and did not 
reflect any specific implementation at the time. Guy Harris and Arthur 
David Olson would likely know the history better, as they were active in 
this area then. The rationale of POSIX 1003.1-1988 cites the early tzdb 
work as the "Olson/Harris method" and says it would be a conforming 
extension to POSIX if it were fixed up a bit (which it was, eventually).