Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/mod.std.unix.v5/text0062.txt

Internet Message Format | 1987-06-30 | 7.0 KB

Date: Thu, 27 Feb 86 15:11:34 PST
From: seismo!sun!guy (Guy Harris)

>   My proposal's biggest (and intended) limitation is its inability to
> deal with past years at all.

You *intended* to make "ctime" only work on times in the current year?  This
is extremely undesirable.  Every UNIX out there can deal with this now, and
people have probably written code that depends on being able to do so.  That
code won't work on a system which doesn't support this.

> 4. Proposed TZ format is too unlike Sys V's. (Guy Harris)
>
>    System V's use of difference is hours is just plain wrong for
>    many places (eg., Dominican Republic, Iran, and Saudi Arabia
>    where local custom dictates midnight is when the sun sets).
>    I proposed using just minutes.  Guy proposes the form "[+/-]H[:m]"
>    where "H" is hours and "m" is minutes.  It's a matter of choice.

It is not in the least "a matter of choice".  For one thing, I'd rather let
the computer do the multiplication of 8 by 60 instead of being forced to do
it myself; computers are good at that sort of thing.  For another, my
proposal is an *upward compatible extension* to the System V syntax (which,
BTW, the item in the System V Interface Definition under "Future
Directions", where the number in TZ becomes a four-digit value of the form
"hhmm", does not seem to be).  Your proposal is not an upward compatible
extension to the System V syntax, as it involves changing the time zone
offset to minutes - i.e., EST5EDT is no longer correct.  There have already
been enough incompatible changes to UNIX by several groups with the intent
of "improving" it (Berkeley's CSRG and AT&T's USDL have both done their
share of this); let's try to keep that sort of thing to a minimum in the
future.  (I.e., don't always take the first solution to a problem that comes
to mind, or even the most aesthetically pleasing solution; sacrificing some
think time or some aesthetic merit for compatibility is almost always the
right thing to do.)

>    It may be preferable to use seconds to be on the safe side.

Given that most clocks used in everyday situations aren't accurate to the
second, the chances of a timezone offset being specified to the second are
somewhere between slim and none, unless you have an offset from UTC
specified to the second due to something like not picking up a leap second
(which I sincerely doubt anybody does).  Specifying the offset down to the
second is overkill (note that 4.2BSD's "gettimeofday" system call fills in a
structure which specifies the offset to the minute; a commendable example of
restraint).

> 5. Who puts TZ and DST into a user's environment? (Guy Harris)
>
>    The easy answer is "whatever puts TZ there now".  It is an OS
>    specific mechanism.  "login" could do it or a user's login shell
>    upon starting up could do it.  I didn't specify in the proposal.
>
> 6. What about utilities not run by a logged-in user? (Guy Harris)
>
>    Such utilities should only have to use a library call to obtain
>    the timezone name (if desired) and the local time.

In this case, the library call in question had better be part of the
standard.  I presume by "the local time" you really meant "the local
timezone offset and the daylight savings time rules for that zone".  As
such, since this implies there is a "default" time zone, why not have all
the routines use this time zone if TZ is not specified in the environment?
That way, 1) programs don't have to "know" that they're going to be run in
such an environment and have the extra calls to get the "default" timezone
information added, and 2) you don't have to bother sticking TZ in the
environment unless you want to work in a timezone other than the default.

> 7. Use files to hold information about that timezone.
>    (steinmetz!davidsen and ncr-sd!greg (Greg Noel))
>
>    Using a file with the name of a timezone won't work for Daylight
>    Saving Time rules because one timezone may span multiple countries
>    with its named unchanged...

Arthur Olson's proposal does not require the file's name to be the same as
the zone.  The zone's name is computed from information in the file.

>    For users of network file systems and diskless workstations: beware,
>    proximity does not imply same rules (for a bad dream, think of a network
>    that spans a timezone where there is only one file server and the rest
>    of the nodes are diskless -- this contrived example is hard to solve
>    with any proposal).

No, it isn't.  Here's how it could be solved, given the way Sun
sets up diskless clients:

    Have the "default time zone" be specified in a file (whether the
    file is a "profile" file which puts it in the environment, or
    a file which is read in by the "get default timezone" routine,
    or whatever is irrelevant) which is, say, in "/etc".  Make it
    a symbolic link to a file in "/private/etc".  "/private", on Sun
    systems, is a small private file system on the server; each client
    has one of its own, to hold things like "/etc/rc.boot" which sets
    the host name for the machine.  Sharing this file between all clients
    obviously won't work, so the precedent for configuration files for
    diskless workstations which can't be shared by all clients of its
    server is already established.

>    The second point is that the name of the timezone has to be known
>    somehow -- both the default timezone and, if the user selects one,
>    the non-system name.  This brings to mind an easy solution of
>    environment variables.

It may be easy, but it's not a solution, unless you can stuff this default
timezone into the environment of every process on the system.  And if you do
so in N different places, as System V currently does, it may be a solution
but it's not easy.

>   Let me close with the requirements, as I see them, for the handling of
> timezone and DST information.  It might be better to debate these instead
> of any specific proposals.

If we're going to debate the requirements, let's not see any specific
proposals until the requirements are settled, so we don't have to shoot down
proposals which either don't meet the requirements or which are more complex
than is needed to meet the requirements (or both!).

> 1. every site must have default information on its timezone and for DST
>    rules

Every *host* must have this information, as you pointed out in the example
of the diskless workstatiions.

> 2. information about the past, while it may be needed in some situations,
>    is not essential
> 3. information about other timezones and areas, while it may be needed
>    in some situations, is not essential

Would you please explain the distinction between "needed" and "essential"?
If it is truly "needed" in some situations, as opposed to "useful", it's
"essential" unless the system can do without a P1003-compatible system.

> 4. a user (or program) should be allowed to change the timezone and DST
>    information for their use only

4 1/2. a consequence of this is that a program must be able to override
       any setting the user has made and get the default timezone for
       that machine

Volume-Number: Volume 5, Number 63