import cvs 2:1.12.13+real-5 (see mircvs://src/gnu/usr.bin/cvs/ for VCS history)
[alioth/cvs.git] / lib / test-getdate.sh
1 #! /bin/sh
2 # $MirOS: ports/devel/cvs/patches/patch-lib_test-getdate_sh,v 1.2 2010/09/18 23:52:26 tg Exp $
3
4 # Test that a getdate executable meets its specification.
5 #
6 # Copyright (C) 2004 Free Software Foundation, Inc.
7 #
8 # This program is free software; you can redistribute it and/or modify
9 # it under the terms of the GNU General Public License as published by
10 # the Free Software Foundation; either version 2, or (at your option)
11 # any later version.
12 #
13 # This program is distributed in the hope that it will be useful,
14 # but WITHOUT ANY WARRANTY; without even the implied warranty of
15 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
16 # GNU General Public License for more details.
17 #
18 # You should have received a copy of the GNU General Public License
19 # along with this program; if not, write to the Free Software Foundation,
20 # Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
21
22
23 # as this uses POSIX behaviour and does not count leap seconds...
24 if test -n "$GETDATE_LD_PRELOAD"; then
25         LD_PRELOAD=$GETDATE_LD_PRELOAD
26         export LD_PRELOAD
27 fi
28
29 ###
30 ### Globals
31 ###
32 LOGFILE=`pwd`/getdate.log
33 if test -f "$LOGFILE"; then
34         mv $LOGFILE $LOGFILE~
35 fi
36
37
38
39 ###
40 ### Functions
41 ###
42 verify ()
43 {
44         echo >>getdate-got
45         if cmp getdate-expected getdate-got >getdate.cmp; then
46                 echo "PASS: $1" >>$LOGFILE
47         else
48                 cat getdate.cmp >>$LOGFILE
49                 echo "** expected: " >>$LOGFILE
50                 cat getdate-expected >>$LOGFILE
51                 echo "** got: " >>$LOGFILE
52                 cat getdate-got >>$LOGFILE
53                 echo "FAIL: $1" | tee -a $LOGFILE >&2
54                 echo "Failed!  See $LOGFILE for more!" >&2
55                 exit 1
56         fi
57 }
58
59
60
61 skip ()
62 {
63         echo "SKIP: $1"${2+" ($2)"} >>$LOGFILE
64 }
65
66
67
68 # Prep for future calls to valid_timezone().
69 #
70 # This should set $UTZ to three spaces, `GMT', `Unrecognized/Unrecognized', or
71 # possibly the empty string, depending on what system we are running on.  With
72 # any luck, this will catch any other existing variations as well.  The way it
73 # is used later does have the disadvantage of rejecting at least the
74 # `Europe/London' timezone for half the year when $UTZ gets set to `GMT', like
75 # happens on NetBSD, but, since I haven't come up with any better ideas and
76 # since rejecting a timezone just causes a few tests to be skipped, this will
77 # have to do for now.
78 #
79 # UTZ stands for Unrecognized Time Zone.
80 UTZ=`TZ=Unrecognized/Unrecognized date +%Z`
81
82 # The following function will return true if $1 is a valid timezone.  It will
83 # return false and set $skipreason, otherwise.
84 #
85 # Clobbers $NTZ & $skipreason.
86 #
87 # SUS2 says `date +%Z' will return `no characters' if `no timezone is
88 # determinable'.  It is, unfortunately, not very specific about what
89 # `determinable' means.  On GNU/Linux, `date +%Z' returns $TZ when $TZ is not
90 # recognized.  NetBSD 1.6.1 "determines" that an unrecognizable value in $TZ
91 # really means `GMT'.  On Cray, the standard is ignored and `date +%Z' returns
92 # three spaces when $TZ is not recognized.  We test for all three cases, plus
93 # the empty string for good measure, though I know of no set of conditions
94 # which will actually cause `date +%Z' to return the empty string SUS2
95 # specifies.
96 #
97 # Due to the current nature of this test, this will not work for the
98 # three-letter zone codes on some systems.  e.g.:
99 #
100 #       test `TZ=EST date +%Z` = "EST"
101 #
102 # should, quite correctly, evaluate to true on most systems, but:
103 #
104 #       TZ=Asia/Calcutta date +%Z
105 #
106 # would return `IST' on GNU/Linux, and hopefully any system which understands
107 # the `Asia/Calcutta' timezone, and `   ' on Cray.  Similarly:
108 #
109 #       TZ=Doesnt_Exist/Doesnt_Exist date +%Z
110 #
111 # returns `Doesnt_Exist/Doesnt_Exist' on GNU/Linux and `   ' on Cray.
112 #
113 # Unfortunately, the %z date format string (-HHMM format time zone) supported
114 # by the GNU `date' command is not part of any standard I know of and,
115 # therefore, is probably not portable.
116 #
117 valid_timezone ()
118 {
119         NTZ=`TZ=$1 date +%Z`
120         if test "$NTZ" = "$UTZ" || test "$NTZ" = "$1"; then
121                 skipreason="$1 is not a recognized timezone on this system"
122                 return `false`
123         else
124                 return `:`
125         fi
126 }
127
128
129
130 ###
131 ### Tests
132 ###
133
134 # Why are these dates tested?
135 #
136 # February 29, 2003
137 #   Is not a leap year - should be invalid.
138 #
139 # 2004-12-40
140 #   Make sure get_date does not "roll" date forward to January 9th.  Some
141 #   versions have been known to do this.
142 #
143 # Dec-5-1972
144 #   This is my birthday.  :)
145 #
146 # 3/29/1974
147 # 1996/05/12 13:57:45
148 #   Because.
149 #
150 # 12-05-12
151 #   This will be my 40th birthday.  Ouch.  :)
152 #
153 # 05/12/96
154 #   Because.
155 #
156 # third tuesday in March, 2078
157 #   Wanted this to work.
158 #
159 # 1969-12-32 2:00:00 UTC
160 # 1970-01-01 2:00:00 UTC
161 # 1969-12-32 2:00:00 +0400
162 # 1970-01-01 2:00:00 +0400
163 # 1969-12-32 2:00:00 -0400
164 # 1970-01-01 2:00:00 -0400
165 #   Playing near the UNIX Epoch boundry condition to make sure date rolling
166 #   is also disabled there.
167 #
168 # 1996-12-12 1 month
169 #   Test a relative date.
170
171
172
173 # The following tests are currently being skipped for being unportable:
174 #
175 # Tue Jan 19 03:14:07 2038 +0000
176 #   For machines with 31-bit time_t, any date past this date will be an
177 #   invalid date. So, any test date with a value greater than this
178 #   time is not portable.
179 #
180 # Feb. 29, 2096 4 years
181 #   4 years from this date is _not_ a leap year, so Feb. 29th does not exist.
182 #
183 # Feb. 29, 2096 8 years
184 #   8 years from this date is a leap year, so Feb. 29th does exist,
185 #   but on many hosts with 32-bit time_t types time, this test will
186 #   fail. So, this is not a portable test.
187 #
188
189 TZ=UTC0; export TZ
190
191 cat >getdate-expected <<EOF
192 Enter date, or blank line to exit.
193 > Bad format - couldn't convert.
194 > Bad format - couldn't convert.
195 >      92361600 =       1972-12-05 00:00:00.000000000
196 >     133747200 =       1974-03-29 00:00:00.000000000
197 >     831909465 =       1996-05-12 13:57:45.000000000
198 >    1336780800 =       2012-05-12 00:00:00.000000000
199 >     831859200 =       1996-05-12 00:00:00.000000000
200 > Bad format - couldn't convert.
201 > Bad format - couldn't convert.
202 >          7200 =       1970-01-01 02:00:00.000000000
203 > Bad format - couldn't convert.
204 >         -7200 =       1969-12-31 22:00:00.000000000
205 > Bad format - couldn't convert.
206 >         21600 =       1970-01-01 06:00:00.000000000
207 >     853027200 =       1997-01-12 00:00:00.000000000
208
209 EOF
210
211 ./getdate >getdate-got <<EOF
212 February 29, 2003
213 2004-12-40
214 Dec-5-1972
215 3/29/1974
216 1996/05/12 13:57:45
217 12-05-12
218 05/12/96
219 third tuesday in March, 2078
220 1969-12-32 2:00:00 UTC
221 1970-01-01 2:00:00 UTC
222 1969-12-32 2:00:00 +0400
223 1970-01-01 2:00:00 +0400
224 1969-12-32 2:00:00 -0400
225 1970-01-01 2:00:00 -0400
226 1996-12-12 1 month
227 EOF
228
229 verify getdate-1
230
231
232
233 # Why are these dates tested?
234 #
235 # Ian Abbot reported these odd boundry cases.  After daylight savings time went
236 # into effect, non-daylight time zones would cause
237 # "Bad format - couldn't convert." errors, even when the non-daylight zone
238 # happened to be a universal one, like GMT.
239
240 TZ=Europe/London; export TZ
241 if valid_timezone $TZ; then
242         cat >getdate-expected <<EOF
243 Enter date, or blank line to exit.
244 >    1109635200 =       2005-03-01 00:00:00.000000000
245 >    1111881600 =       2005-03-27 00:00:00.000000000
246 >    1111968000 =       2005-03-28 01:00:00.000000000
247 >    1111968000 =       2005-03-28 01:00:00.000000000
248 >    1112054400 =       2005-03-29 01:00:00.000000000
249 >    1112054400 =       2005-03-29 01:00:00.000000000
250 >    1112140800 =       2005-03-30 01:00:00.000000000
251 >    1112140800 =       2005-03-30 01:00:00.000000000
252 >    1112227200 =       2005-03-31 01:00:00.000000000
253 >    1112227200 =       2005-03-31 01:00:00.000000000
254 >    1112313600 =       2005-04-01 01:00:00.000000000
255 >    1112313600 =       2005-04-01 01:00:00.000000000
256 >    1113091200 =       2005-04-10 01:00:00.000000000
257 >    1113091200 =       2005-04-10 01:00:00.000000000
258 >    1112310000 =       2005-04-01 00:00:00.000000000
259
260 EOF
261
262         ./getdate >getdate-got <<EOF
263 2005-3-1 GMT
264 2005-3-27 GMT
265 2005-3-28 GMT
266 2005-3-28 UTC0
267 2005-3-29 GMT
268 2005-3-29 UTC0
269 2005-3-30 GMT
270 2005-3-30 UTC0
271 2005-3-31 GMT
272 2005-3-31 UTC0
273 2005-4-1 GMT
274 2005-4-1 UTC0
275 2005-4-10 GMT
276 2005-4-10 UTC0
277 2005-4-1 BST
278 EOF
279
280         verify getdate-2
281 else
282         skip getdate-2 "$skipreason"
283 fi
284
285
286
287 # Many of the following cases were also submitted by Ian Abbott, but the same
288 # errors are not exhibited.  The original problem had a similar root, but
289 # managed to produce errors with GMT, which is considered a "Universal Zone".
290 # This was fixed.
291 #
292 # The deeper problem has to do with "local zone" processing in getdate.y
293 # that causes local daylight zones to be excluded when local standard time is
294 # in effect and vice versa.  This used to cause trouble with GMT in Britian
295 # when British Summer Time was in effect, but this was overridden for the
296 # "Universal Timezones" (GMT, UTC, & UT), that might double as a local zone in
297 # some locales.  We still see in these tests the local daylight/standard zone
298 # exclusion in EST/EDT.  According to Paul Eggert in a message to
299 # bug-gnulib@gnu.org on 2005-04-12, this is considered a bug but may not be
300 # fixed soon due to its complexity.
301
302 TZ=America/New_York; export TZ
303 if valid_timezone $TZ; then
304         cat >getdate-expected <<EOF
305 Enter date, or blank line to exit.
306 >    1109653200 =       2005-03-01 00:00:00.000000000
307 >    1109631600 =       2005-02-28 18:00:00.000000000
308 >    1112331600 =       2005-04-01 00:00:00.000000000
309 > Bad format - couldn't convert.
310 >    1114902000 =       2005-04-30 19:00:00.000000000
311 >    1114905600 =       2005-04-30 20:00:00.000000000
312 >    1114920000 =       2005-05-01 00:00:00.000000000
313 >    1114905600 =       2005-04-30 20:00:00.000000000
314 > Bad format - couldn't convert.
315 >    1117580400 =       2005-05-31 19:00:00.000000000
316 >    1117584000 =       2005-05-31 20:00:00.000000000
317 >    1117598400 =       2005-06-01 00:00:00.000000000
318 >    1117584000 =       2005-05-31 20:00:00.000000000
319
320 EOF
321
322         ./getdate >getdate-got <<EOF
323 2005-3-1 EST
324 2005-3-1 BST
325 2005-4-1 EST
326 2005-5-1 EST
327 2005-5-1 BST
328 2005-5-1 GMT
329 2005-5-1 EDT
330 2005-5-1 UTC0
331 2005-6-1 EST
332 2005-6-1 BST
333 2005-6-1 GMT
334 2005-6-1 EDT
335 2005-6-1 UTC0
336 EOF
337
338         verify getdate-3
339 else
340         skip getdate-3 "$skipreason"
341 fi
342
343
344
345 rm getdate-expected getdate-got getdate.cmp
346 exit 0