Garrett's analysis of the cause of the Africa/Monrovia problem is accurate (see the end of this message). The conservative approach to fixing the problem would be as shown just below. The more radical approach would be to ditch the saved_seconds hackery completely; it predates the conditional normalize_overflow(&yourtm.tm_min, &yourtm.tm_sec, SECSPERMIN) call that now appears in the code, which should do what the saved_seconds hackery was designed to do. --ado *** 7.73/localtime.c Tue Jun 5 14:04:57 2001 --- 7.74/localtime.c Tue Jun 5 14:04:57 2001 *************** *** 1383,1389 **** } if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) return WRONG; ! if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) { /* ** We can't set tm_sec to 0, because that might push the ** time below the minimum representable time. --- 1383,1391 ---- } if (increment_overflow(&yourtm.tm_year, -TM_YEAR_BASE)) return WRONG; ! if (yourtm.tm_sec >= 0 && yourtm.tm_sec < SECSPERMIN) ! saved_seconds = 0; ! else if (yourtm.tm_year + TM_YEAR_BASE < EPOCH_YEAR) { /* ** We can't set tm_sec to 0, because that might push the ** time below the minimum representable time. -----Original Message----- From: Garrett Wollman [mailto:wollman@khavrinen.lcs.mit.edu] Sent: Friday, May 25, 2001 2:01 PM To: tz@elsie.nci.nih.gov Subject: [akr@m17n.org: bin/27630: mktime problem.] A FreeBSD user submitted the following bug report. I'm curious as to whether the current tzcode still has this problem. My analysis follows at the end. -GAWollman ... For example, TZ=Africa/Monrovia, 1972/05/01 00:44:30 cannot be converted to time_t. Since this example is taken from `zdump -v Africa/Monrovia' and it is after Epoch, there is no reason to fail. ... This problem appears to result from the `saved_seconds' hackery in time2(): saved_seconds = yourtm.tm_sec; yourtm.tm_sec = 0; time2() then goes on to attempt to find (in this example) 1972-05-01T00:44:00, which does not exist in this time zone, and returns failure.