Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!amdcad!lll-crg!mordor!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: POSE proposal for TZ
Message-ID: <4168@ut-sally.UUCP>
Date: Tue, 11-Feb-86 23:07:42 EST
Article-I.D.: ut-sally.4168
Posted: Tue Feb 11 23:07:42 1986
Date-Received: Wed, 12-Feb-86 20:01:53 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 127
Approved: j...@sally.UUCP
>From: seismo!hao!asgb!benish!devine
Date: Tue, 11 Feb 86 11:21:51 mst
Hi, here is a letter that I sent to the IEEE mailing address for
POSE proposals. It deals with timezones and Daylight Saving Time
rules and how to incorporate them portably into a UNIX environment.
Its advantages are: follows System III/V model; allows users and
programs to override system timezone information; works for all
present country TZ and DST rules; and flexibility.
Bob Devine; 3133 Lake Park Way; Longmont, CO 80501; (303) 772-2410
(seismo!hao!asgb!devine sdcrdcf!bmcg!asgb!devine)
---------------------------------------------------------------------
Secretary, IEEE Standards Board
Institute of Electrical and Electronics Engineers
345 East 17th Street
New York, NY 10017
This is a suggested resolution for the handling of world timezones
and Daylight Saving Time for the P1003/Portable Operating System
Environment document. Appendix A.3 asked for such a resolution.
The major points of the proposal are:
1. There is a world-readable, superuser-modifiable file
named "/etc/TIMEZONE" that describes the per-system
timezone information and Daylight Saving Time rules.
2. TIMEZONE contains the following lines in Bourne shell
syntax:
TZ=ABC
DST="dst1 dst2"
export TZ DST
3. The TZ variable has 2 required parts (and an optional 3rd):
A = standard abbreviation for the timezone as used by the
local area
A :== [A-Z][A-Z]*
B = plus or minus difference in minutes from Universal Time,
plus for those locations east of GMT, minus for west
B :== [+-][0-9][0-9][0-9]
C = standard abbreviation for the timezone as used by the
local area when Daylight Saving Time is in effect. This
part of TZ may be absent if DST is not used.
C :== [A-Z][A-Z]*
Example for my location in Boulder, Colorado, USA:
TZ=MST-420MDT
4. The DST variable has 0 or 2 parts in the string. It has
zero if no Daylight Saving Time is observed or 2, when DST
starts and ends, for those places that do observe it. I
have been unable to locate any place in the world that has
1, 3, or more changes per year to its local time. If DST
is not null, the string means:
dst1 = a string that describes when DST starts
dst2 = a string that describes when DST stops
Both have the syntax of "mmddDhhMM%CCcc". Translating it:
mm = the month (January = 01)
dd = the day of the month (01 to 31)
D = the "search-forward" function number
(0-7) usually 1 or 0
0 = use the day mm/dd without translation
1 = search forward to the first Sunday
2 = " Monday
3 = " Tuesday
4 = " Wednesday
5 = " Thursday
6 = " Friday
7 = " Saturday
hh = the hour at which the change goes into effect
(00-23) usually 01, 02 or 03
MM = the minute at which the change goes into effect
(00-59) usually 00
% = a '+' or a '-' saying what direction to move
CC = how many hours to move (00-23) usually 01 or 02
cc = how many minutes to move (00-23) usually 00
Example for my location in Boulder, Colorado, USA in 1986:
DST="042410200+0100 102510200-0100"
Alternately, if I already know the exact dates that DST
starts and ends for that year, I can use:
DST="042700200+0100 102600200-0100"
5. If the file is unreadable or missing, the default time
zone to use is GMT and the default DST is null.
6. The library call "localtime()" is the only system code
that need interpret the TZ and DST variables.
7. TZ and DST are put into the environment of each user
when the user logs in. A user can change create their
own TZ and DST values and replace the system maintained
values in their environment.
8. Those utilities that strip off environment information
can obtain TZ and DST values by reading "/etc/TIMEZONE".
Bob Devine
(303) 530-6635
Burroughs Distributed Systems Group
6655 Lookout Road
Boulder, CO. 80301
UUCP: ihnp4!seismo!hao!asgb!devine OR sdcrdcf!bmcg!asgb!devine
Volume-Number: Volume 5, Number 47
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4173@ut-sally.UUCP>
Date: Wed, 12-Feb-86 12:16:01 EST
Article-I.D.: ut-sally.4173
Posted: Wed Feb 12 12:16:01 1986
Date-Received: Fri, 14-Feb-86 00:41:00 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 30
Approved: j...@sally.UUCP
Date: Wed, 12 Feb 86 04:26:15 EST
>From: Chris Torek <ch...@MIMSY.UMD.EDU>
I have tried to stay out of this discussion since I know little of
existing time zone standards and have never needed anything but
the 4BSD system time zone. However, I would like to ask that the
following suggested rule be amended:
>4. The DST variable has 0 or 2 parts in the string. It has
> zero if no Daylight Saving Time is observed or 2, when DST
> starts and ends, for those places that do observe it. I
> have been unable to locate any place in the world that has
> 1, 3, or more changes per year to its local time.
Rest assured that the moment this became a standard and everyone
conformed to it (comments upon the likelyhood of that eventuality
notwithstanding), Murphy would strike and Congress would legistlate
some really crazy DST rules.
I see no good reason for requiring the string to have exactly 0 or
2 parts (efficiency of specific implementations does not count as
a good reason).
(I suspect also that once this were standardised, someone would
come up with a time zone name that requires a digit or a plus or
minus sign, making rule 3 unworkable as well....)
Chris
Volume-Number: Volume 5, Number 48
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: mod.std.unix
Message-ID: <4186@ut-sally.UUCP>
Date: Thu, 13-Feb-86 11:59:03 EST
Article-I.D.: ut-sally.4186
Posted: Thu Feb 13 11:59:03 1986
Date-Received: Fri, 14-Feb-86 03:39:42 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 30
Approved: j...@sally.UUCP
>From: harvard!cybvax0!vcvax1!paul (Paul Kleppner)
Date: Wed, 12 Feb 86 18:58:56 est
Bob Devine's proposal on the /etc/TIMEZONE format (volume 5, #47)
looks to me like a good solution to a complicated problem.
I do have one suggestion, though: don't clutter the /etc/TIMEZONE file
with Bourne shell syntax. If the file contained only the two actual values
(separated by a space or tab) and not the "TZ=", "DST=",
and "export" comands, it would be much easier to read by non-Bourne
shells or by other programs, which would otherwise have to filter
out the shell statements.
I should point out that there is no loss in efficiency with this approach.
The login initialization file /etc/profile, instead of containing the line,
. /etc/TIMEZONE
would contain the lines
read TZ DST < /etc/TIMEZONE
export TZ DST
(I believe this will work correctly whether DST has 0 or 2 parts.)
------------
Paul Kleppner
VenturCom, Inc.
617/661-1230
{seismo!harvard,genrad!mit-eddie}!cybvax0!vcvax1!paul
Volume-Number: Volume 5, Number 49
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!amdcad!lll-crg!mordor!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4190@ut-sally.UUCP>
Date: Fri, 14-Feb-86 07:12:31 EST
Article-I.D.: ut-sally.4190
Posted: Fri Feb 14 07:12:31 1986
Date-Received: Sat, 15-Feb-86 01:52:27 EST
References: <4186@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 169
Approved: j...@sally.UUCP
Date: Fri, 14 Feb 86 00:51:16 PST
>From: sun!...@seismo.UUCP (Guy Harris)
> The major points of the proposal are:
>
> 1. There is a world-readable, superuser-modifiable file
> named "/etc/TIMEZONE" that describes the per-system
> timezone information and Daylight Saving Time rules.
Too specific. The standard should not give all the implementation details.
Giving this much detail merely constrains an implementation to use the
particular technique specified, even if it isn't the appropriate technique
to use (on a V7 or 4BSD system, for instance, fetching it from the kernel is
more appropriate, since it's already there).
> 3. The TZ variable has 2 required parts (and an optional 3rd):
>
> A = standard abbreviation for the timezone as used by the
> local area
> A :== [A-Z][A-Z]*
> B = plus or minus difference in minutes from Universal Time,
> plus for those locations east of GMT, minus for west
> B :== [+-][0-9][0-9][0-9]
> C = standard abbreviation for the timezone as used by the
> local area when Daylight Saving Time is in effect. This
> part of TZ may be absent if DST is not used.
> C :== [A-Z][A-Z]*
Unnecessarily incompatible with System V, which specifies the offset from
Universal Time in hours. (It also requires you to multiply an offset in
hours by 60, which is much better done by a computer.) See below for a
better way of specifying offsets which aren't an integral number of hours.
> 4. The DST variable has 0 or 2 parts in the string. It has
> zero if no Daylight Saving Time is observed or 2, when DST
> starts and ends, for those places that do observe it.
Not sufficient. The routines that convert between GMT and local time can be
given a time not in the current year; if the time is in a year prior to the
current one, these routines must still be able to convert it, and must
therefore know the rules for all years prior to the current one. (The
4.2BSD source indicates that the rules for 1970, 1971, and 1972 in Australia
were all rather different; 1970 had no daylight savings time, 1971 had it
from October 31 to the end of the year, 1972 had it from January 1 to
February 27 and October 31 to December 31, and all subsequent years had it
January 1 to March 7 and October 31 to December 31. In the US, of course,
we had the infamous "nixonflag" for 1974 and 1975....) For times in the
future, of course, it will have to rely on a projection (if it could handle
times in the future exactly, I'd put it to work on Sun's stock price...).
> 7. TZ and DST are put into the environment of each user
> when the user logs in.
>
> 8. Those utilities that strip off environment information
> can obtain TZ and DST values by reading "/etc/TIMEZONE".
What puts TZ and DST into the environment of each user? If it's not done by
"login", then every program which is used as a login shell must do it. A
LOT of UNIX systems have many users who log in to a specific application,
which may never run the shell. As such, it should be done by "login", which
makes the Bourne shell syntax unhelpful.
And what about utilities not run by a logged-in user? Must they look in
"/etc/TIMEZONE"? If so, do they have to do their own parsing? There is
already a routine in System V called "tzset()", which sets the global
variables "timezone" and "daylight". In vanilla S5, it just scans the TZ
environment variable (which means you have to go through contortions to get
that variable set). In systems which have a source for time zone
information other than TZ, they can scan TZ if present and non-null, and use
that source otherwise. In your proposal, "tzset()" should scan that file.
However, we have now eliminated the need for any program to look at
"/etc/TIMEZONE" directly - they should let "tzset()" do it for them.
The trouble is that there are several ways of storing the time zone
information, other than in the TZ environment variable. V7 stored it,
in effect, in "/unix"; you specified it when you built your kernel. 4.2BSD
also stores it there (in "/vmunix", actually); you can specify it when you
build your kernel, but you can also specify it with the "settimeofday"
system call. A system running on a machine with an EEPROM might store the
time zone there, and either read it out when the machine is booted or make
it readable by user programs. A "hosted" system (i.e., a system which
provides a P1003-compatible environment on top of an existing operating
system) might be able to get it out of the host operating system. A table
containing this operation might be mapped into the address space of all
processes in any of a number of ways, depending on the memory model of the
OS and the whims of the OS's designers.
It's inappropriate to commit to something as specific as "/etc/TIMEZONE";
"tzset()" should be specified as fetching the appropriate information and
setting the "timezone", "daylight", and "tzname" external variables (System
V-style) and also arranging, somehow, for the daylight savings time rules to
be set up.
The only copy of the X3J11 C standard draft I can get my hands on right now
is an old one. It lists "asctime", "ctime", "gmtime", and "localtime" as
being like their UNIX versions, but doesn't list "tzset", "timezone",
"daylight", or "tzname". Presumably, it considers them to be part of the
operating system (or environment) rather than the C language/library. (Have
they been added in later drafts?) If they haven't been added in later
drafts, I propose that P1003 adopt the System V versions, as specified in
the System V Interface Definition, with the following change:
change
...the external variable "daylight" is non-zero only if the
standard U.S.A. Daylight Savings Time conversion should be
applied. The program compensates for the peculiarities
of this conversion in 1974 and 1975; if necessary, a table
for these years can be extended.
If an environment variable named TZ is present, "asctime" uses the
contents of the variable to override the default time zone. The
value of TZ must be a three-letter time zone name, followed
by an optional minus sign (for zones east of Greenwich) and
a series of digits representing the difference between local time
and Greenwich Mean Time in hours; this is followed by an
optional three-letter name for a daylight time zone.
to
...the external variable "daylight" is non-zero only if the
standard Daylight Savings Time conversion for the current time
zone, if any, should be applied. The external variable "tzname"
contains pointers to the name of the time zone when daylight
savings time is not in effect and when it is in effect in its
first and second members, respectively.
The default time zone is settable by the system administrator,
and is usually the time zone that the majority of the system's
users are in. "tzset" normally sets the variables "timezone",
"daylight", and "tzname" to the values for the default time zone.
If an environment variable named TZ is present, "tzset" sets the
variables "timezone", "daylight", and "tzname" from the value
of this environment variable. The value of TZ must either be
of the form "GMT+hh[:mm]", or "GMT-hh[:mm]", specifying an
unnamed time zone "hh" hours and "mm" minutes ahead of or behind
Universal Time (if "mm" is not present, it is assumed to be
zero), or a zone name followed by an optional minus sign (for
zones east of Greenwich) and a specification of the form "hh[:mm]"
specifying the difference between local time and Universal Time
in hours and minutes; this is followed by an optional name for the
time zone when Daylight Savings Time is in effect. A time zone name
must not contain any digits and must not contain the characters "+",
"-", or ":". If an unnamed zone is specified, Daylight Savings
time rules are considered not to apply, and the time zone name is
assumed to be the value of the TZ environment variable.
I include the "GMT+/-hh:mm" specification on the assumption that there are
unnamed time zones; if this is not so, this part may be deleted. Note that
unlike the System V TZ value, this permits time zone names to be longer or
shorter than 3 characters. It also permits fractional-hour time zone
offsets; it uses a different syntax than the one described in the "FUTURE
DIRECTIONS" section, because that section doesn't indicate whether the
time zone offset must be four digits (which would mean that EST5EDT would no
longer be valid) or not (which would mean that OLT7ODT would be ambiguous -
is Out to Lunch Time 7 hours away from GMT or 7 minutes?). The proposed
syntax is an upward-compatible extension of the current syntax, which the
syntax in the "FUTURE DIRECTIONS" section is not.
If TZ is not set, "tzset" will presumably get the Daylight Savings Time
rules from some standard place (where it gets them from is an implementation
detail which does not belong in P1003). If TZ is set, there should be some
indication of where it gets the DST rules from. It can either get them from
some "standard" database of rules, or from an environment variable (either
from additional data at the end of TZ, or from DST), or both (i.e., if the
rules aren't specified in an environment variable, it uses the time zone
specified in TZ to look up the rules in the standard database).
Volume-Number: Volume 5, Number 50
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4209@ut-sally.UUCP>
Date: Tue, 18-Feb-86 15:59:02 EST
Article-I.D.: ut-sally.4209
Posted: Tue Feb 18 15:59:02 1986
Date-Received: Wed, 19-Feb-86 04:15:25 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 12
Approved: j...@sally.UUCP
Date: Sun, 16 Feb 86 00:31:47 cst
>From: ihnp4!uiucdcs!ccvaxa!ag...@SEISMO.CSS.GOV (Andy Glew)
Pardon me if I've missed anything in this discussion, but has anyone
considered the possiblity of double daylight savings time - not just
two hours offset, but 2 hours in the deep of summer and one hour in
spring and fall (or, one hour's saving in summer, none in fall, and
an "unsaving" in deepest winter).
[ I don't recall anyone mentioning that before. -mod ]
Volume-Number: Volume 5, Number 51
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4210@ut-sally.UUCP>
Date: Tue, 18-Feb-86 16:02:52 EST
Article-I.D.: ut-sally.4210
Posted: Tue Feb 18 16:02:52 1986
Date-Received: Wed, 19-Feb-86 04:16:10 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 28
Approved: j...@sally.UUCP
>From: hao!asgb!dev...@seismo.UUCP (Bob Devine)
Date: Mon, 17 Feb 86 18:00:40 mst
>>From: Chris Torek <ch...@MIMSY.UMD.EDU>
>>Discussion of (1) why Daylight Saving Time should not be constrained
>>to either 0 or 2 changes per year; and (2) cautioning against a
>>timezone name that may contain numerals, '+', or '-'. Both points
>>emphasized the possibility of future bizarre changes.
Yes, I was aware and worried about both problems. However, in my
search of timezones and DST rules worldwide I was not able to find any
current or past rules that would have violated the assumptions. Future
rules are unlikely to break the current conventions for fear of confusing
everybody (it's bad enough now).
Parsing the strings for TZ _COULD_ be done using reserved characters
but that would really break the old usage of the TZ environment variable.
I'm hoping to only bend it. Likewise, the library call that interprets
the DST strings _COULD_ be written in a generalized fashion to handle any
number of DST changes per year. However, I don't think such effort is
required.
Bob Devine
(BTW, Sys V spell doesn't have "timezone" in its dictionary.)
Volume-Number: Volume 5, Number 52
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!genrad!panda!talcott!harvard!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4223@ut-sally.UUCP>
Date: Wed, 19-Feb-86 22:31:19 EST
Article-I.D.: ut-sally.4223
Posted: Wed Feb 19 22:31:19 1986
Date-Received: Sat, 22-Feb-86 02:56:01 EST
References: your article <4210@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 13
Approved: j...@sally.UUCP
>From: seismo!umcp-cs!aplvax!osiris!phil (Philip Kos)
> Bob Devine
> (BTW, Sys V spell doesn't have "timezone" in its dictionary.)
Neither does 4.2, at least on our Pyramid.
Phil Kos
The Johns Hopkins Hospital, Baltimore, MD
Volume-Number: Volume 5, Number 53
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!genrad!panda!talcott!harvard!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4226@ut-sally.UUCP>
Date: Thu, 20-Feb-86 09:14:02 EST
Article-I.D.: ut-sally.4226
Posted: Thu Feb 20 09:14:02 1986
Date-Received: Sat, 22-Feb-86 02:52:11 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 43
Approved: j...@sally.UUCP
Date: Wed, 19 Feb 86 17:58:51 est
From: seismo!cbosgd.ATT.UUCP!mark (Mark Horton)
> Yes, I was aware and worried about both problems. However, in my
>search of timezones and DST rules worldwide I was not able to find any
>current or past rules that would have violated the assumptions. Future
>rules are unlikely to break the current conventions for fear of confusing
>everybody (it's bad enough now).
You haven't looked hard enough. Also, the minute you make an assumption,
some congressman or some MP in Britain or Japan or wherever will violate it.
>>>Discussion of (1) why Daylight Saving Time should not be constrained
>>>to either 0 or 2 changes per year;
There is a thing called "Double Daylight Time" which does exactly that.
I think it happened a few years back in some other country (Canada?)
Surely someone on this list can provide details.
>>>and (2) cautioning against a
>>>timezone name that may contain numerals, '+', or '-'. Both points
>>>emphasized the possibility of future bizarre changes.
On the contrary, the notion of giving a time zone a name is an American
notion. They also have names in Europe and Australia, but my impression
is that in many parts of the world, such as Japan, time zones are named
according to the ISO format +HHMM, e.g. Japan is +0900.
I'm afraid the variable TZ is already pretty badly broken - it can't be
used in Newfoundland or Central Australia or Saudi Arabia. (We do have
sites on Usenet in Newfoundland - as far as I know, they all run 4BSD.)
elsie!ado has written some code with a much more flexible structure
(and some additional complexity, which I think is unavoidable.) I
understand he's going to submit it to this group shortly. I think
it merits serious consideration. How much goes into the standard and
how much is left to the implementor isn't clear (e.g. is the format
of the time zone description file part of the standard?) but the code
is intended to be public domain, and it ought to make a good start.
Mark
Volume-Number: Volume 5, Number 54
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!bellcore!ulysses!mhuxr!mhuxt!mhuxv!akgua!gatech!
ut-sally!std-unix
From: std-u...@ut-sally.UUCP
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4238@ut-sally.UUCP>
Date: Fri, 21-Feb-86 14:11:54 EST
Article-I.D.: ut-sally.4238
Posted: Fri Feb 21 14:11:54 1986
Date-Received: Sat, 22-Feb-86 03:29:32 EST
References: <4190@ut-sally.UUCP> <4186@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 55
Approved: j...@sally.UUCP
From: seismo!kobold!ncr-sd!greg
Date: Thu, 20 Feb 86 19:54:17 pst
Organization: NCR Corporation, Rancho Bernardo
In article <4186@ut-sally> Bob Devine proposes a standard method to hold
the timezone information, which keeps the information in a file in a format
suitable for interpretation by the (Bourne) shell.
In article <4...@ut-sally.UUCP> Guy Harris replies:
> ....
>Too specific. The standard should not give all the implementation details.
> ....
>Unnecessarily incompatible with System V, which specifies the offset from
> ....
>Not sufficient. The routines that convert between GMT and local time can be
> ....
>What puts TZ and DST into the environment of each user? If it's not done by
> ....
>And what about utilities not run by a logged-in user? Must they look in
> ....
I agree; the scheme is flawed by all of those problems and more. I don't
have any skill with words (in the way they are used in specifications), but
I would propose that any scheme adopted by the standards commitee should have
the following requirements:
- There should be a way that a system administrator could specify a global
(system-wide) default that is not process-tree related. In other words,
it can't depend upon something in the environment.
- There should be a way that this can be overridden so that non-default
timezones can be supported. Presumably, this can be done on a process-
tree basis; i.e., it can be carried in the environment.
- It should be possible to handle things like multiple timezone changes
per year (double daylight savings, like during WWII) and timezone changes
that are not exactly one hour (didn't Newfoundland once have a daylight
savings change of 1.5 hours?).
Personally, I think a better scheme is the one presented here a month or so
ago, where the timezone information lives in a directory with one file for
each timezone and with the standard timezone linked to a default name. A user
could override the default by specifying one of the files in an environment
variable, or roll his own file and specify the full path name. The file
would contain:
- The timezone offset and default name.
- The rules for the normal conversion and the name for it.
- Exceptional periods, the offset, and the name.
Here I am being too specific myself, but I wanted to point out that Bob Devine
has done us a great service by articulating a mechanism for describing the
normal conversion (the second point above); whether this information is to
be included in the file and processed on the fly or pre-processed by some
program into a binary table that can be evaluated quickly is an implementation
consideration.
-- Greg Noel, NCR Rancho Bernardo G...@ncr-sd.UUCP or G...@nosc.ARPA
Volume-Number: Volume 5, Number 55
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!amdcad!lll-crg!mordor!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4257@ut-sally.UUCP>
Date: Sun, 23-Feb-86 12:19:07 EST
Article-I.D.: ut-sally.4257
Posted: Sun Feb 23 12:19:07 1986
Date-Received: Sun, 23-Feb-86 16:57:56 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 518
Approved: j...@sally.UUCP
From: seismo!elsie!ado
Date: Fri, 21 Feb 86 22:48:58 EST
# To unundle, sh this file
echo README 1>&2
cat >README <<'End of README'
@(#)README 1.4
The shell archive of which this file is a part contains man pages for functions
and a file format designed to deal with Daylight Savings Time variations.
The basic idea is to have a system-wide directory that contains binary files
describing time zone rules; functions such as "localtime" could read such
files before doing time conversions.
A manual page for a "time zone compiler" that turns text-file descriptions of
time zone rules into binary files is also included, as is a sample input file
for the compiler. These would, of course, not be part of the standard;
they are included here only to show that the binary files that would be used
under this scheme can be readily created.
Source code for these functions and for the time zone compiler are available
from seismo!elsie!ado, the person to whom to direct comments (with, perhaps,
carbon copes to cbosgd!mark and seismo!philabs!linus!encore!necis!geo,
who are responsible for any good ideas that show up here).
End of README
Code
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!...@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
Volume-Number: Volume 5, Number 57
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!amdcad!lll-crg!mordor!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4258@ut-sally.UUCP>
Date: Sun, 23-Feb-86 12:40:38 EST
Article-I.D.: ut-sally.4258
Posted: Sun Feb 23 12:40:38 1986
Date-Received: Sun, 23-Feb-86 16:58:15 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 70
Approved: j...@sally.UUCP
Date: Sat, 22 Feb 86 21:14:28 cst
From: ihnp4!uiucdcs!ccvaxa!ag...@SEISMO.CSS.GOV (Andy Glew)
I do not know if double daylight savings has ever been used,
but I heard a man from Canada's NRC talking about it on CBC radio last year.
The NRC is hoping that the US will go to DST earlier and stay later,
and from that it is only a short step to double time.
This makes better sense the closer you get to the pole.
I do know that several industries in Britain in WWII went to effective
double daylight savings time, by having people report to work earlier
in deepest summer (which is what we should do anyway).
What's all the fuss about, anyway? All times should be recorded in GMT,
since it's the closest thing we have to a standard clock.
Timezone information should only be used for local printing of the time
- dates, ls, etc. For this, the environment variable would be useful.
[ Several people have described what the problems are at length.
Since it's been a while, naturally there are people just starting
to follow the discussion who missed its beginning. Perhaps I should
repost one of the explanatory articles. So, a small poll: If you've
come in late and want to know what all the fuss is about, send me
a note. If you've been following the discussion all along and remember
a particular specification of the problem which was most clear to you,
let me know. If I get enough of the former I will repost an
explanatory article, possibly chosen according to the latter. -mod ]
Timestamps MUST be recorded in GMT, for projects that exchange code across
timezones.
[ The UNIX kernel has always kept internal time in GMT, as have most
other operating systems (VMS seems to be an exception). There are,
however, programs which write text timestamps in local time. -mod ]
It is conceivable that knowing what time of his local day the author last
modified his code might be useful, but instead of carrying a timezone
indication, why not carry a true location around, like latitude/longitude,
and look that up in a database (although it might get hairy for spaceships
travelling near c :-).
[ Timezones change per latitude and longitude. -mod ]
Even hairier idea: have we considered non-24 hour days? Someday, someone is
going to have computers on the moon; they may still be running UNIX (and
Fortran, and Cobol) at that time, and there's no guarantee that they'll
stick to a 24 hour day. There've been a lot of studies that show that men
in isolation go to a 28-30 hour cycle, and without the sun rising to keep
you in synch, there's no reason not to change the definition of "day".
GMT will probably still be kept, but local time takes on a whole new meaning.
Maybe just leave an escape in any timezone environment variable for
local time conversions that don't simply consist of adding an offset?
[ Doubtless it will happen, but probably not within the effective
life of the current P1003 proposed standard. I suggest the new
INFO-FUTURES list for such discussions. I will repost the announcement
from UNIX-WIZARDS for it as the next article. -mod ]
Andy "Krazy" Glew. Gould CSD-Urbana.
UUCP: ...!ihnp4!uiucdcs!ccvaxa!aglew
ARPA Internet: ag...@gswd-vms.ARPA
[ PS: Other than interpolating comments, there are exactly two things
which I can't resist doing to submitted articles before posting them
and without asking their authors first: fixing obviously incorrect
spelling; and fixing incorrect network addresses, like UUCP addresses
given as being for USENET or old-style ARPANET addresses which won't
work anywhere in the ARPA Internet where domain nameservers are in use.
-mod ]
Volume-Number: Volume 5, Number 58
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4284@ut-sally.UUCP>
Date: Tue, 25-Feb-86 23:02:15 EST
Article-I.D.: ut-sally.4284
Posted: Tue Feb 25 23:02:15 1986
Date-Received: Fri, 28-Feb-86 02:29:08 EST
References: <4257@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 63
Approved: j...@sally.UUCP
From: Jack Jansen <seismo!mcvax!jack>
Date: 25 Feb 86 20:56:12 N (Tue)
Organization: AMOEBA project, CWI, Amsterdam
Well, even though the discussion doesn't seem to have anything
to do with standardising, it *is* interesting.
[ Comments on how to handle timezones are explicitly requested
in an appendix of the current P1003 draft. -mod ]
I like the outside of elsie!ado's proposal, but I think the
implementation could be done more simple and cheap.
First (not too important), if you go for binary files, you
shouldn't put two arrays of fixed size in the beginning.
This will inevitably mean trouble for future generation. If you
*do* insist on binary data, make it variable sized array, and
put a count in.
Second, and most important, I think the method is far too complex
for its achievements. I think something along the following
lines would work as easy, and be much simpler to set up:
- view normal time and dst as *different* timezones. If a certain
area has had more than one dst offset since written history(jan70),
see those as different too. Note that different timezones could
have the same name.
- Per timezone, keep a list with transition-times, and new timezones.
- Further, use a scheme along the lines of elsie!ado's proposal, so
use files in a specified directory, and use a link to get the
local default time.
Now, two typical files would look like:
/etc/tz/FOT:
# FOT - Far Out Time.
FOT +11:28 # Offset from GMT
Apr 1, 1970 FST
Apr 1, 1971 FST
Apr 1, 1972 FST.1972
...
/etc/tz/FST:
# FST - Far out Summer Time.
# Differs by 1:10 hour from FST.
FST +12:38
Sep 1, 1970 FOT
...
/etc/tz/FST.1972:
# FST.2 - Far out Summer Time exceptional situation for 1972.
# Differs 1:11 hour from FOT.
FST +12:39
Sep 1, 1972 FOT
Note that these files should be in binary, of course, and transition
times in order of ascending magnitude.
Also, if you do a settz("FST"), and present a date in november,
a quick binary search will immedeately get you to the Sep 1 transition,
and get you to the right timezone. Note that this will *also* work for
timezones with the same names: the name in col. 2 of the files, and in
the settz() call, are filenames, and the first entry in the file is
the name that will be used on output.
--
Jack Jansen, j...@mcvax.UUCP
The shell is my oyster.
Volume-Number: Volume 5, Number 61
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!pyramid!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4293@ut-sally.UUCP>
Date: Wed, 26-Feb-86 11:56:45 EST
Article-I.D.: ut-sally.4293
Posted: Wed Feb 26 11:56:45 1986
Date-Received: Fri, 28-Feb-86 02:59:58 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 144
Approved: j...@sally.UUCP
From: seismo!hao!asgb!devine (Bob Devine)
Date: Tue, 25 Feb 86 19:58:51 mst
First of all, sorry for the length of this article. I've been
doing job search type of things the last week.
It appears that this will be my last posting from this site.
The Burroughs Distributed Systems Group was severely cut for budget
reasons. The uucp site "asgb" (it stood for Advanced Systems Group,
Boulder) will soon be no more. In fact, there are only a few
terminals left attached to any VAX. Our site officially closed
a week and a half ago.
There has been many responses to my proposal for the handling
of timezones and Daylight Saving Time rules. Let me respond to
them according to subject. However, let me first reiterate the
important ideas presented in my proposal of a month ago:
1. a single timezone definition exists for that system;
this definition is the default
2. timezone and DST rules are kept and passed as
environment variables
3. a user (or program) can override the default definition
The above can be considered a "cleaned-up" way of handling timezone
compared to AT&T System III and V. DST handling is just an analogous
extension to this. I proposed this method to deal with the coming
UNIX usage throughout the world. Specifically, the product line we
were developing used UNIX and was to be offered everywhere Burroughs
does business.
My proposal's biggest (and intended) limitation is its inability to
deal with past years at all. To do that requires a table of such
changes as elsie!ado's proposes. However, after I started collecting
such rules and saw that they numbered in the thousands I decided for
the simpler proposal. If anyone wants to, they can see my collection
gathered from a person from the DOT, someone at the National Bureau of
Standards, and several publications from the American Federation of
Astrologers. However, any collection becomes old quickly. For example,
China just this month started using 4 timezones instead of the one
centered on Bejing.
On to the criticisms and questions:
1. Format of proposed DST variable. Are 0 or 2 changes per year
sufficient? (Chris Torek, Mark Horton and Andy Glew)
I believe so for all places __currently__. The only places that
I have found to use Double Summer Time are:
Argentina 1924 and 1969
Azores 1942 (unclear)
France some areas 1940-42
everywhere 1943-46 and 1976-77
Great Britain 1941-47
Portugal 1942
Spain 1942-1946
Tunisia 194x (unclear)
If Double Summer Time is in modern use, four changes can be put
into the DST variable. Re-reading my response to Chris Torek,
I see that I was unclear. I wrote that no rules would "violate the
assumptions" made for the DST variable. What was not clear was
the assumption that 4 changes could be used.
2. Numerals, '-', or '+' in timezone names. (Chris Torek and Mark Horton)
I don't know. Does anyone have a list of legal timezone names
and abbreviations (if any) as used by each country? I have English
equivalents for some. The TZ variable can be modified to use
field separator characters between the names and offset from UT.
A note: the sign used for the offset should match ISO standards,
which is the opposite of System V conventions. Sorry, I don't have
the ISO document number than details this; it's in a box somewhere.
3. "/etc/TIMEZONE" is too specific. Use functions. (Guy Harris)
For the purpose of P1003, Guy is right. To avoid the confusion
of all new CTIME(3C) functions, the existing functions should be
kept though with modifications. A problem lurks in the use of
the ctime() function where programs copy the returned string into
a too short array.
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 may be preferable to use seconds to be on the safe side.
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.
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 (eg., Canada and USA) yet the countries may
have different rules for daylight saving time. Furthermore, within
one country, not all areas within a timezone use DST the same way
(eg., Indiana, Arizona). A two dimensional grid of timezones and
countries might be possible but this would probably get unwieldy quickly.
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).
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.
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.
1. every site must have default information on its timezone and for DST rules
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
4. a user (or program) should be allowed to change the timezone and DST
information for their use only
5. because the local time conversion is used often, it should be fast
6. changes to the system-default information should be easy to make
So long,
Bob Devine
(home phone: 303/772-2410)
Volume-Number: Volume 5, Number 62
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ut-sally.UUCP
Path: utzoo!decvax!decwrl!amdcad!lll-crg!mordor!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: POSE proposal for TZ
Message-ID: <4323@ut-sally.UUCP>
Date: Thu, 27-Feb-86 20:50:05 EST
Article-I.D.: ut-sally.4323
Posted: Thu Feb 27 20:50:05 1986
Date-Received: Sat, 1-Mar-86 01:11:35 EST
References: <4293@ut-sally.UUCP>
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 141
Approved: j...@sally.UUCP
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