The attached is redistributed with permission of the original author.
--ado
...
From: dupuy(a)hudson.cs.columbia.edu (Alexander Dupuy)
Message-Id: <9204280549.AA22287(a)hudson.cs.columbia.edu>
To: ado(a)ncifcrf.gov, sunbugs(a)sun.com
Subject: bug in ctime() for bogus values of TZ (SPARC/SunOS 4.1.1)
Reply-To: dupuy(a)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
