a letter from hpfcdg!rgt


Wed Jul 13 23:14:41 UTC 2011


	From seismo!hplabs!hpfcla!hpfclj!hpfcdg!rgt Thu Dec  4 08:57:02 1986
	To: elsie!ado
	Subject: ctime proposal

ado,

Please feel free to circulate this to the ctime community.

>Guy Harris has sent me corrections and additions to the latest versions of
>the time zone stuff--and, in particular, has added some code to "newctime.c"
>both for better System V compatibility and to provide the "mktemp" function
>specified in recent versions of the X3J11 (a.k.a. C Standard) committee's
>drafts.  If you'd like to receive the new versions, let me know.

mktemp is really mktime, I assume.

>Here's a table summarizing the current state of agreement among various
>existing and proposed sets of time-handling functions.  One idea for
>getting better agreement follow the table.

I have added X3J11 and X/OPEN to the extent that I  understand  them.  I
have also  restated  HP to reflect  what is  currently  implemented  and
available, not what I thought we might get from a compromise package.

		Variables and functions provided by. . .

                V.2     4.3     HP      X3J11   X/OPEN  ado     guy
------------------------------------------------------------------------------
ctime()         yes     yes     yes     ??      yes     yes     yes
localtime()     yes     yes     yes     ??      yes     yes     yes
gmtime()        yes     yes     yes     ??      yes     yes     yes
asctime()       yes     yes     yes     ??      yes     yes     yes
long timezone   yes     no      yes     ??      yes     no      yes
int daylight    yes     no      yes     ??      yes     no      yes
char *tzname[2] yes     no      yes     ??      yes     yes     yes
tzset()         yes     no      yes     ??      yes     yes     yes
timezone()      no      yes     no      ??      no      no      no    (5)
dysize(int y)   no      yes     no      ??      no      no      yes   (1)
nl_ctime        no      no      yes     ??      yes     no      no    (4)
nl_asctime      no      no      yes     ??      yes     no      no    (4)
nl_cxtime       no      no      yes     ??      yes     no      no    (4)
nl_ascxtime     no      no      yes     ??      yes     no      no    (4)
strftime        no      no      no      yes     no      no      no    (4)
zonetime()      no      no      no      ??      no      yes     yes
settz()         no      no      no      ??      no      yes     yes
mktime()        no      no      no      yes     no      no      yes   (2)
gmtime2()       no      no      yes     ??      no      no      yes   (3)

>	(1)  This  undocumented  Berkeley  function  returns  366 if its
>	     (single integer)  argument is divisible by four; it returns
>	     365 otherwise.

This is not strictly  correct for the Gregorian  Era, although it is for
1970 to 2037 (or was that 190?  to 2037)  multiples of 100 should return
365 except multiples of 100 and 400 which should return 366.

>	(2)  As  described  in  recent  X3J11  committee   drafts,  this
>	     function ".  .  .converts the broken-down  time,  expressed
>	     as local  time, in the  [struct  tm]  pointed  to by  [it's
>	     argument] into a calendar time value with the same encoding
>	     as that of the values returned by the time function."

	(3)  gmtime2 is the inverse of gmtime,  converting  a time value
	     in the tm structure  into a calendar time value.  Currently
	     it is static and undocumented.

	(4)  nl_ctime, nl_asctime, nl_cxtime,  nl_ascxtime, and strftime
	     all  are  designed  add  a)  formatting  capability  and b)
	     locale-specific month and day names.  These 5 can easily be
	     merged to one or two routines.

	     For  those  who  have  not  seen  X3J11/86-125R  by  D.  F.
	     Prosser, strftime() is defined as:

		int strftime(str, n, format, tp)
		char *str;	/* return string */
		int n;		/* maximum string length */
		char *format;	/* format string similar to date + */
		struct tm *tp;	/* time value structure */

	(5) timezone()  is not adequate for an  international  standard.
	    It  assumes  that the time zone name (EST) or DST name (EDT)
	    can be derived simply from the offset from GMT.

>A way I see of getting better agreement is to eliminate "settz" and "zonetime". 
>The capabilities these functions provide can, for the most part,
>be provided by direct manipulation of the environment variable TZ,
>combined with "tzset" calls (assuming, of course, that good-enough functions
>for environment manipulation are available.)
>True, it means more work for programmers interested in changing time zones--
>but the need to do so is rare, and the extra work will pay off 
>since the results of the work will be somewhat more portable
>(in particular, will be more portable to existing System V environments).

>Any comments on the above idea?  Any other ideas?

May I suggest the following be done immediately:

     1) From the subset  above, I would  like to suggest  that we select
        the following:

			V.2     4.3     HP      X3J11   X/OPEN  ado     guy
	-------------------------------------------------------------------
	ctime()         yes     yes     yes     ??      yes     yes     yes
	localtime()     yes     yes     yes     ??      yes     yes     yes
	gmtime()        yes     yes     yes     ??      yes     yes     yes
	asctime()       yes     yes     yes     ??      yes     yes     yes
	long timezone   yes     no      yes     ??      yes     no      yes
	int daylight    yes     no      yes     ??      yes     no      yes
	char *tzname[2] yes     no      yes     ??      yes     yes     yes
	tzset()         yes     no      yes     ??      yes     yes     yes
	dysize(int y)   no      yes     no      ??      no      no      yes
	strftime()      no      no      no      yes     no      no      no
	strasftime()    no      no      no      no      no      no      no
	gmtime2()       no      no      yes     ??      no      no      yes

     2) Add long  tm_tzadj to tm  structure.  It is incorrect  to assume
	that one hour should be added or  subtracted  based on tm_isdst.
	For example,  parts of Indiana are on CDT when  tm_isdst is true
	and EST when  tm_isdst is false.  This will  correctly  indicate
	whether  tzname[0]  or  tzname[1]  should be used.  However  the
	actual offset from GMT does not change.

	This gives analogs to daylight and timezone  external  variables
	which  are  applicable  to the time  value  contained  in the tm
	structure.

		struct tm {
			int	tm_sec;
			int	tm_min;
			int	tm_hour;
			int	tm_mday;
			int	tm_mon;
			int	tm_year;
			int	tm_wday;
			int	tm_yday;
			int	tm_isdst;
			long	tm_tzadj;
		};

     3) Select  gmtime2()  over  mktime()  since it is a true inverse of
	gmtime().  The result of gmtime2() can  trivially be modified to
	correct for local time using tm_tzadj mentioned above.

     4) Define a strasftime() which is (as a parallel to ctime()):

		return(strftime(str, n, format, localtime(clock));

     5) Retain  the  System V  Release  2 syntax  for TZ.  In  addition,
	augment it to handle handle minutes such as  TZ=CST-9:30CDT  for
	for Queensland, Australia.

     6) settz("value") may be approximated as putenv("TZ=value"); tzset()

     7) Augment  field   descriptors   for  date(1)  to  parallel  X3J11
	strftime()  proposal.  In most  cases  strftime()  uses  date(1)
	descriptors.

In the future we should also address:

     8) Look at time()  values  beyond 1970 to 2037.  P1003 has  already
	done some work here.

     9) Look at the difference between GMT and UTC (Universal Coordiated
	Time -- this is the correct  name and correct  abbreviation).  I
	believe that GMT uses seconds of variable  length to accommodate
	the  inaccuracies  of  nature.  UTC on the other  hand uses leap
	seconds.  It is UTC which is  generally  available  from WWV and
	other international time standard sources.


Ron Tolley



More information about the tz mailing list