Proposed asctime-related changes

Paul Eggert eggert at CS.UCLA.EDU
Thu Aug 5 19:28:06 UTC 2004


"Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov> writes:

> Below are proposed asctime-related changes to the time zone package

Thanks.  I compiled and tested them and have a couple of thoughts.

First, GCC warns about zdump.c's new signed-versus-unsigned comparisons
"timeptr->tm_wday >= sizeof ...." and similarly for tm_mon.  The
comparisons aren't needed here, since the values are guaranteed to be
in range, so the easiest fix is to remove them.

Second, it'd be nice if the asctime/ctime documentation explains more
of the stuff we've discussed recently.

Here are proposed further patches along these lines: they assume
the patches you just sent.

===================================================================
RCS file: RCS/newctime.3,v
retrieving revision 2004.2.1.1
retrieving revision 2004.2.1.1.0.1
diff -pu -r2004.2.1.1 -r2004.2.1.1.0.1
--- newctime.3	2004/08/05 16:04:29	2004.2.1.1
+++ newctime.3	2004/08/05 19:20:33	2004.2.1.1.0.1
@@ -45,8 +45,12 @@ string of the form
 .eo
 Thu Nov 24 18:22:48 1986\n\0
 .br
-.ce
 .ec
+where \en and \e0 represent a newline and null character, respectively.
+Years requiring fewer than four characters are padded with
+trailing spaces.
+The year before the year 1 is the year 0, the year before that is
+the year \-1, and so forth.
 For years longer than four characters, the string is of the form
 .br
 .ce
@@ -54,8 +58,11 @@ For years longer than four characters, t
 Thu Nov 24 18:22:48     81986\n\0
 .ec
 .br
+with five spaces before the year.  This unusual format is designed to
+make it less likely that older software that expects exactly 26 bytes
+of output will mistakenly output misleading values for out-of-range years.
 .PP
-.IR Localtime\^
+.I Localtime\^
 and
 .I gmtime\^
 return pointers to ``tm'' structures, described below.
@@ -213,6 +220,20 @@ will also be overwritten at the next cal
 (and by calls to
 .IR tzset ).
 .PP
+.I Asctime\^
+and
+.I ctime\^
+behave strangely for years before 1000 or after 9999.
+The 1989 and 1999 editions of the C Standard say
+that years from \-99 through 999 are converted without
+extra spaces, but this conflicts with longstanding
+tradition and with this implementation.
+Traditional implementations of these two functions are
+restricted to years in the range 1900 through 2099.
+To avoid this portability mess, new programs should use
+.I strftime\^
+instead.
+.PP
 Avoid using out-of-range values with
 .I mktime
 when setting up lunch with promptness sticklers in Riyadh.
===================================================================
RCS file: RCS/zdump.c,v
retrieving revision 2004.2.1.1
retrieving revision 2004.2.1.1.0.1
diff -pu -r2004.2.1.1 -r2004.2.1.1.0.1
--- zdump.c	2004/08/05 16:04:29	2004.2.1.1
+++ zdump.c	2004/08/05 19:19:36	2004.2.1.1.0.1
@@ -378,26 +378,9 @@ static void
 dumptime(timeptr)
 register const struct tm *	timeptr;
 {
-	static const char	wday_name[][3] = {
-		"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"
-	};
-	static const char	mon_name[][3] = {
-		"Jan", "Feb", "Mar", "Apr", "May", "Jun",
-		"Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
-	};
-	register const char *	wn;
-	register const char *	mn;
-
-	if (timeptr->tm_wday < 0 ||
-		timeptr->tm_wday >= sizeof wday_name / sizeof wday_name[0])
-			wn = "???";
-	else		wn = wday_name[timeptr->tm_wday];
-	if (timeptr->tm_mon < 0 ||
-		timeptr->tm_mon >= sizeof mon_name / sizeof mon_name[0])
-			mn = "???";
-	else		mn = mon_name[timeptr->tm_mon];
 	(void) printf("%.3s %.3s%3d %.2d:%.2d:%.2d %ld",
-		wn, mn,
+		"SunMonTueWedThuFriSat" + 3 * timeptr->tm_wday,
+		"JanFebMarAprMayJunJulAugSepOctNovDec" + 3 * timeptr->tm_mon,
 		timeptr->tm_mday, timeptr->tm_hour,
 		timeptr->tm_min, timeptr->tm_sec,
 		timeptr->tm_year + (long) TM_YEAR_BASE);




More information about the tz mailing list