[tz] Java & Rearguard

[Guy Harris]

On Jun 3, 2019, at 1:19 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> 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.

As per my previous "more than you ever wanted to know about the history of time zone handling in UNIX since V7" email

	1) it was less "ditched" than "not adopted", as not all systems had adopted it;

	2) at least some, if not all, of the systems using it had adopted tzcode, making that API element obsolete;

	3) that API element was largely used only by localtime() and mktime(), so invisible to most applications doing conversion between UNIX time and local time;

so I suspect the problems were more for OS vendors then for applications - and even those were minimal for vendors who had adopted tzcode - or independently implemented it.

> 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?);

The standard time offset from UTC was a kernel setting, and you had to rebuild the kernel and reboot or, if you're ambitious, fire up adb, as root, against /unix and /dev/kmem and patch the variable.

The time zone rules were compiled into ctime(), and you had to change it, rebuild it, relink programs that needed the new localtime(), and reinstall the new library and executables.

> presumably this inspired the gettimeofday API you mention, which was introduced some time between 4BSD (1980-10) and  4.1cBSD (1982-12),

Probably in one of the 4.1[a-z]BSD releases, as it was, as I remember, present in 4.2BSD.

> and was declared obsolete sometime between 4.3BSD Reno (1990-06) and 4.4BSD (1993-06);

...because they'd picked up tzcode.

> presumably Linux (released before 4.4BSD came out) picked up the API from 4.3BSD.

Many OSes picked up gettimeofday(), mainly to be able to get time stamps with finer-than-one-second resolution.

As I remember, Roland McGrath put an independent implementation of code to use the tzdb into GNU libc (there are probably emails about it in the timezone mailing list archives), so Linux would have had a tzcode-equivalent implementation of localtime()/mktime() since the first "GNU/Linux" was available, and would have had no need for the second argument to gettimeofday().

> 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,

That dates back to System III, if not earlier.

> but it made the kernel setting (and thus the 2nd argument of gettimeofday) obsolete.

System Roman Numeral never had gettimeofday() (until SVR4); I don't know whether it picked up ftime() from V7 and then dropped it in favor of the TZ environment variable or whether whatever AT&T group was handling the internal "product" versions of UNIX decided, either before V7 added ftime() or when they found out about ftime(), to go with an environment-variable based system instead.

> 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.

It seems to reflect the SVR3.1 implementation; the current Single UNIX Specification rationale doesn't seem to mention SVR3.1 or any other existing practice in the "Environment Variables" section.

> 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 I eventually got people to stop mentioning my name - I guess if you want to call it the Olson/Elz/Harris/... method (apologies to others subsumed into the "..."), you can go ahead, but as a non-originator I don't deserve any more credit than any other non-originator (Arthur being the originator, with the initial code and announcement).

> and says it would be a conforming extension to POSIX if it were fixed up a bit (which it was, eventually).

":Europe/Berlin" is a TZ setting allowed by the SUS (and maybe by 1988 POSIX, which I *think* had the : prefix); its behavior is implementation-defined by the SUS.  So, yes, in that sense it's conforming.