std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/12/86)
>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 47std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/12/86)
Date: Wed, 12 Feb 86 04:26:15 EST >From: Chris Torek <chris@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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/14/86)
Date: Fri, 14 Feb 86 00:51:16 PST >From: sun!guy@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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/18/86)
Date: Sun, 16 Feb 86 00:31:47 cst
>From: ihnp4!uiucdcs!ccvaxa!aglew@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 51std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/19/86)
>From: hao!asgb!devine@seismo.UUCP (Bob Devine) Date: Mon, 17 Feb 86 18:00:40 mst >>From: Chris Torek <chris@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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/20/86)
>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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/20/86)
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
std-unix@ut-sally.UUCP (02/21/86)
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 <4190@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 Greg@ncr-sd.UUCP or Greg@nosc.ARPA Volume-Number: Volume 5, Number 55
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/23/86)
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
echo settz.3 1>&2
cat >settz.3 <<'End of settz.3'
.TH SETTZ 3
.SH NAME
settz, newctime, newlocaltime \- convert date and time to ASCII
.SH SYNOPSIS
.nf
.B settz(zonename)
.B char *zonename;
.PP
.B char *newctime(clock)
.B long *clock;
.PP
.B
#include "time.h"
.PP
.B struct tm *newlocaltime(clock)
.B long *clock;
.PP
.B char *tz_abbr;
.SH DESCRIPTION
.I Settz
sets time zone information used by
.I newctime
and
.IR newlocaltime .
If
.I zonename
begins with a slash,
it is used as the absolute pathname of the
.IR tzfile (5)-format
file from which to read the time zone information;
if
.I zonename
begins with some other character,
it is used as a pathname relative to the standard time zone information
directory. A call of the form
.ti +.5i
.B
settz("")
.br
causes built-in information about GMT to be used; a call of the form
.ti +.5i
.B
settz((char *) 0)
.br
is treated as if it were a call of the form
.ti +.5i
.B
settz("localtime")
.PP
.I Newlocaltime
has the same argument and return value as
.IR localtime .
If
.I newlocaltime
is called before
.I settz
is called,
.I newlocaltime
calls
.I settz
with the value returned by
.B
getenv("TZ").
.I Newlocaltime
sets
tz_abbr
to a pointer to an
ASCII string that's the time zone abbreviation to be used with
.IR newlocaltime 's
return value.
.PP
.I Newctime
returns a pointer to a string of the form
.ti +.5i
Sat Feb 15 15:45:51 1986 EST\\n\\0
.br
where the last (variable-width) field is the time zone abbreviation.
.SH DIAGNOSTICS
.I Settz
returns zero if all seems well; it returns negative one otherwise
(and sets things up so that its built-in information about GMT is used).
.SH FILES
/etc/tzdir standard time zone information directory
.SH "SEE ALSO"
ctime(3), getenv(3), tzfile(5)
.. @(#)settz.3 1.3
End of settz.3
echo tzfile.5 1>&2
cat >tzfile.5 <<'End of tzfile.5'
.TH TZFILE 5
.SH NAME
tzfile \- time zone information
.SH SYNOPSIS
.B
#include "tzfile.h"
.SH DESCRIPTION
The time zone information files used by
.IR settz (3)
and
.IR newlocaltime (3)
have the format of the
.I tzinfo
structure described in the include file
.B
"tzfile.h":
.sp
.nf
.in +.5i
struct tzinfo {
int tz_timecnt;
long tz_times[TZ_MAX_TIMES];
char tz_types[TZ_MAX_TIMES];
struct dsinfo {
long ds_gmtoff;
char ds_abbr[TZ_ABBR_LEN+1];
char ds_isdst;
} tz_dsinfo[TZ_MAX_TYPES];
};
.fi
.PP
The
.B tz_timecnt
field tells how many of the
.B tz_times
and
.B tz_types
stored in the file are meaningful.
Each of the meaningful
.B tz_times
entries is a starting time (as returned by
.IR time (2));
the same-indexed
.B tz_types
entry is the index of the
.B tz_dsinfo
array element that tells about how "local time" is generated starting at that
time.
For a file to be used by
.IR settz ,
its
.B tz_times
entries must be sorted in ascending order.
.PP
In the
.B tz_dsinfo
structures,
.B ds_gmtoff
gives the number of seconds that should be added to GMT;
.B ds_abbr
is the ASCII-NUL-terminated string used as the time zone abbreviation;
and
.B
ds_isdst
tells whether
.B
tm_isdst
should be set by
.IR newlocaltime (3).
.PP
.I Newlocaltime
uses the first element of
.B tz_dsinfo
if either
.B tz_timecnt
is zero or
.IR newlocaltime 's
argument is less than
.BR tz_times[0] .
.SH SEE ALSO
settz(3)
.. @(#)tzfile.5 1.4
End of tzfile.5
echo tzcomp.8 1>&2
cat >tzcomp.8 <<'End of tzcomp.8'
.TH TZCOMP 8
.SH NAME
tzcomp \- time zone compiler
.SH SYNOPSIS
.B tzcomp
[
.B \-d
directory ] filename ...
.SH DESCRIPTION
.I Tzcomp
reads text from the file(s) named on the command line
and creates the time zone information files specified in this input.
If a
.I filename
is
.BR ` - ',
the standard input is read.
.PP
This option is available:
.TP
.B \-d directory
Create time zone information files in the named directory rather than
in the standard directory named below.
.PP
A sharp characters (#) in the input introduces a comment which extends to
the end of the line the sharp character appears on.
Any line which is blank (after comment stripping) is ignored.
Non-blank lines are expected to be of one of three
types: rule lines, zone lines, and link lines.
.PP
A rule line has the form
.nf
.B
.ti +.5i
.ta \w'Rule 'u +\w'MostNA 'u +\w'FROM 'u +\w'1973 'u +\w'TYPE 'u +\w'Apr 'u +\w'lastSun 'u +\w'2:00 'u +\w'SAVE 'u
.sp
Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
.sp
For example:
.ti +.5i
.sp
Rule MostNA 1969 1973 - Apr lastSun 2:00 1:00 D
.sp
.fi
The fields that make up a rule line are:
.TP
.B NAME
Gives the (arbitrary) name of the set of rules this rule is part of.
.TP
.B FROM
Gives the first year in which the rule applies.
.TP
.B TO
Gives the last year in which the rule applies.
The word
.RB ` only '
may be used to repeat the value of the
.B
FROM
field.
.TP
.B TYPE
Gives the type of year in which the year applies. If
.B TYPE
is
.B
"-"
then the rule is taken to apply in all years between
.B FROM
and
.B TO
inclusive.
If
.B TYPE
is something else, then the command
.B
.ti +.5i
years from to type
.br
is executed with arguments
.IR from ,
.IR to ,
and
.IR type
taken from the rule line; the rule is taken to apply only in those years
printed by the
.I years
command.
The distributed
.I years
command is a shell script that can handle year types
.B uspres
(United States presidential election years)
and
.B nonpres
(all other years);
other year types may be added by changing the script.
.TP
.B IN
Names the month in which the rule takes effect. Month names may be
abbreviated.
.TP
.B ON
Gives the day on which the rule takes effect.
Recognized forms include:
.nf
.in +.5i
.sp
.ta \w'lastSun 'u
5 the fifth of the month
lastSun the last Sunday in the month
lastMon the last Monday in the month
Sun>=8 first Sunday on or after the eighth
Sun<=25 last Sunday on or before the 25th
.fi
.in -.5i
.sp
Names of days of the week may be abbreviated or spelled out in full.
Note that there must be no spaces within the
.B ON
field
(or within any other field).
.TP
.B AT
Gives the time of day at which the rule takes affect.
Recognized forms include:
.nf
.in +.5i
.sp
.ta \w'1:28:13 'u
2 time in hours
2:00 time in hours and minutes
15:00 24-hour format time (for times after noon)
1:28:14 time in hours, minutes, and seconds
.fi
.in -.5i
.sp
.TP
.B SAVE
Gives the amount of time to be added to local standard time when the rule is in
effect. This field has the same format as the
.B AT
field.
.TP
.B LETTER/S
Gives the "variable part" (for example, the 'S' or 'D' in "EST" or "EDT")
of time zone abbreviations to be used when this rule is in effect.
If this field is
.B
"-",
the variable part is null.
.PP
A zone line has the form
.sp
.nf
.ti +.5i
.ta \w'Zone 'u +\w'Eastern 'u +\w'GMTOFF 'u +\w'MostNA 'u
Zone NAME GMTOFF RULES FORMAT
.sp
For example:
.sp
.ti +.5i
Zone Eastern -5:00 MostNA E%sT
.sp
.fi
The fields that make up a zone line are:
.TP
.B NAME
The name of the time zone.
This is the name used in creating the time zone information file for the zone.
.TP
.B GMTOFF
The amount of time to add to GMT to get standard time in this zone.
This field has the same format as the
.B AT
and
.B SAVE
fields of rule lines;
begin the field with a minus sign if time must be subtracted from GMT.
.TP
.B RULES
The name of the rule(s) that apply in the time zone.
If this field contains
.B
"-"
then standard time always applies in the time zone.
.TP
.B FORMAT
The format for time zone abbreviations in this time zone.
The pairs of characters
.B
"%s"
is used to show where the "variable part" of the time zone abbreviation goes.
.PP
A link line has the form
.sp
.nf
.ti +.5i
.ta \w'Link 'u +\w'LINK-FROM 'u
Link LINK-FROM LINK-TO
.sp
For example:
.sp
.ti +.5i
Link Eastern EST5EDT
.sp
.fi
The
.B LINK-FROM
field should appear as the
.B NAME
field in some zone line;
the
.B LINK-TO
field is used as an alternate name for that zone.
.PP
Lines may appear in any order in the input.
.SH EXAMPLE
[Since a sample time zone file appears in the shell archive,
this section has been omitted.]
.SH FILES
/etc/tzdir standard directory used for created files
.SH "SEE ALSO"
settz(3), tzfile(5)
.. @(#)tzcomp.8 1.4
End of tzcomp.8
echo tzinfo 1>&2
cat >tzinfo <<'End of tzinfo'
# @(#)tzinfo 1.5
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule MostNA 1969 1973 - Apr lastSun 2:00 1:00 D
Rule MostNA 1969 1973 - Oct lastSun 2:00 0 S
Rule MostNA 1974 only - Jan 6 2:00 1:00 D
Rule MostNA 1974 only - Nov 24 2:00 0 S
Rule MostNA 1975 only - Feb 23 2:00 1:00 D
Rule MostNA 1975 only - Oct 26 2:00 0 S
Rule MostNA 1976 2037 - Apr lastSun 2:00 1:00 D
Rule MostNA 1976 2037 - Oct lastSun 2:00 0 S
# Almost surely wrong:
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule Oz-Eur 1969 1973 - Apr lastSun 2:00 1:00 S
Rule Oz-Eur 1969 1973 - Oct lastSun 2:00 0 -
Rule Oz-Eur 1974 only - Jan 6 2:00 1:00 S
Rule Oz-Eur 1974 only - Nov 24 2:00 0 -
Rule Oz-Eur 1975 only - Feb 23 2:00 1:00 S
Rule Oz-Eur 1975 only - Oct 26 2:00 0 -
Rule Oz-Eur 1976 2037 - Apr lastSun 2:00 1:00 S
Rule Oz-Eur 1976 2037 - Oct lastSun 2:00 0 -
# New names
# Zone NAME GMTOFF RULES FORMAT
Zone Atlantic -4:00 MostNA A%sT
Zone Eastern -5:00 MostNA E%sT
Zone Central -6:00 MostNA C%sT
Zone Mountain -7:00 MostNA M%sT
Zone Pacific -8:00 MostNA P%sT
Zone Yukon -9:00 MostNA Y%sT
Zone Hawaiian -10:00 MostNA H%sT
Zone Newfoundland -3:30 - NST
Zone Japan 9:00 - JST
Zone WET 0 Oz-Eur WE%sT
Zone MET 1 Oz-Eur ME%sT
Zone EET 2 Oz-Eur EE%sT
Zone AEST 10:00 Oz-Eur AES%sT
Zone ACST 9:30 Oz-Eur ACS%sT
Zone AWST 8:00 - AWST # No Daylight Saving here?
#
# A settz("") uses the code's built-in GMT without going to disk to get
# the information. Still, we want things to work if somebody does a
# settz("GMT"), so. . .
#
Zone GMT 0 - GMT
# Old names
# Link LINK-FROM LINK-TO
Link Eastern EST5EDT
Link Central CST6CDT
Link Mountain MST7MDT
Link Pacific PST8PDT
# "Pacific Presidential Election Time" is being contemplated in Congress
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule Twilite 1969 1973 - Apr lastSun 2:00 1:00 D
Rule Twilite 1969 1973 - Oct lastSun 2:00 0 S
Rule Twilite 1974 only - Jan 6 2:00 1:00 D
Rule Twilite 1974 only - Nov 24 2:00 0 S
Rule Twilite 1975 only - Feb 23 2:00 1:00 D
Rule Twilite 1975 only - Oct 26 2:00 0 S
Rule Twilite 1976 2037 - Apr lastSun 2:00 1:00 D
Rule Twilite 1976 1987 - Oct lastSun 2:00 0 S
Rule Twilite 1988 2037 uspres Oct lastSun 2:00 1:00 PE
Rule Twilite 1988 2037 uspres Nov Sun>=7 2:00 0 S
Rule Twilite 1988 2037 nonpres Oct lastSun 2:00 0 S
# Zone NAME GMTOFF RULES FORMAT
Zone New-Pacific -8:00 Twilite P%sT
# Next really belongs in a separate file
Link Eastern localtime
End of tzinfo
exit
--
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA
DEC, VAX and Elsie are Digital Equipment and Borden trademarks
Volume-Number: Volume 5, Number 57std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/23/86)
Date: Sat, 22 Feb 86 21:14:28 cst From: ihnp4!uiucdcs!ccvaxa!aglew@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: aglew@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
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/26/86)
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, jack@mcvax.UUCP
The shell is my oyster.
Volume-Number: Volume 5, Number 61std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/26/86)
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 62std-unix@ut-sally.UUCP (Moderator, John Quarterman) (02/28/86)
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