The attached is redistributed with permission of the original author. --ado ... From: dupuy@hudson.cs.columbia.edu (Alexander Dupuy) Message-Id: <9204280549.AA22287@hudson.cs.columbia.edu> To: ado@ncifcrf.gov, sunbugs@sun.com Subject: bug in ctime() for bogus values of TZ (SPARC/SunOS 4.1.1) Reply-To: dupuy@cs.columbia.edu Status: RO As noted in the script and output below, the output of ctime() is incorrect when the TZ environment variable is set to a string which contains a "-" or "+" but which is not present in the the zoneinfo database. It appears that the numeric value of the string following the "+" or "-" (0 if non-numeric) is treated as an offset from UTC, and either the first three characters of TZ or the string preceding the "+" or "-", (whichever is longer) is used as the zone letters. This behavior occurs regardless of the string preceding the "+" or "-", although using "GMT" provides the most convincing bogus timestamp. As a result, it is trivially easy to generate bogus time strings up to 24 hours in the past or future, using "TZ=GMT+24" or "TZ=GMT-24". While one might attempt to call it a feature to allow arbitrary offsets to be specified by the TZ environment variable (is this for compatibility with an old System V feature?) at the very least the zone letters should include the entire TZ environment variable so that spoofing isn't possible. However, the offset is computed in the opposite sense of the offset computed in the "GMT+/-XX" timezones present in the zoneinfo database. For this reason, and because it's quite easy to add timezones to the database, I would strongly argue that this is not in any way a useful feature, and that the correct behavior when presented with an invalid timezone is to use GMT with no offset, and indicate it as GMT. Note also that "GMT+14" is not present in the database, even though the USNO tables indicate that East Siberia (Uelen) was 14 hours ahead of GMT in the summer. I think this may no longer be the case, as I believe most timezones were shifted back (both summer and winter) when Russia declared independence. Still, it is at least a valid historical timezone name... ... @alex _______________________________________________________________________________ $ cat tzfun #!/bin/sh echo -n "GMT : " TZ=GMT date echo "" offsets="11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26" for o in $offsets do echo -n "GMT+$o : " TZ=GMT+$o date done echo "" for o in $offsets do echo -n "FOO-$o : " TZ=FOO-$o date done # $ ./tzfun GMT : Tue Apr 28 03:52:57 GMT 1992 GMT+11 : Tue Apr 28 14:52:57 GMT+1100 1992 GMT+12 : Tue Apr 28 15:52:58 GMT+1200 1992 GMT+13 : Tue Apr 28 16:52:58 GMT+1300 1992 GMT+14 : Mon Apr 27 13:52:58 GMT 1992 GMT+15 : Mon Apr 27 12:52:58 GMT 1992 GMT+16 : Mon Apr 27 11:52:58 GMT 1992 GMT+17 : Mon Apr 27 10:52:58 GMT 1992 GMT+18 : Mon Apr 27 09:52:58 GMT 1992 GMT+19 : Mon Apr 27 08:52:58 GMT 1992 GMT+20 : Mon Apr 27 07:52:59 GMT 1992 GMT+21 : Mon Apr 27 06:52:59 GMT 1992 GMT+22 : Mon Apr 27 05:52:59 GMT 1992 GMT+23 : Mon Apr 27 04:52:59 GMT 1992 GMT+24 : Mon Apr 27 03:52:59 GMT 1992 GMT+25 : Tue Apr 28 03:52:59 GMT 1992 GMT+26 : Tue Apr 28 03:52:59 GMT 1992 FOO-13 : Tue Apr 28 13:53:02 FOO 1992 FOO-11 : Tue Apr 28 14:53:02 FOO 1992 FOO-12 : Tue Apr 28 15:53:02 FOO 1992 FOO-13 : Tue Apr 28 16:53:02 FOO 1992 FOO-14 : Tue Apr 28 17:53:02 FOO 1992 FOO-15 : Tue Apr 28 18:53:02 FOO 1992 FOO-16 : Tue Apr 28 19:53:02 FOO 1992 FOO-17 : Tue Apr 28 20:53:02 FOO 1992 FOO-18 : Tue Apr 28 21:53:02 FOO 1992 FOO-19 : Tue Apr 28 22:53:02 FOO 1992 FOO-20 : Tue Apr 28 23:53:03 FOO 1992 FOO-21 : Wed Apr 29 00:53:03 FOO 1992 FOO-22 : Wed Apr 29 01:53:03 FOO 1992 FOO-23 : Wed Apr 29 02:53:03 FOO 1992 FOO-24 : Wed Apr 29 03:53:03 FOO 1992 FOO-25 : Tue Apr 28 03:53:03 FOO 1992 FOO-26 : Tue Apr 28 03:53:03 FOO 1992