bug in mktime() normalization?

[Tom Peterson (USG)]

> This was to handle leap seconds properly.  On systems that support
> leap seocnds, it's incorrect to normalize the seconds count first,
> since you don't know how many seconds there are per minute until you
> determine which minutes you're talking about.

Similarly, it seems we don't really know which minute we're talking 
about until the excess seconds are factored in (enter chicken & egg).  
Rather than rejecting a tm struct simply because when we set aside it's 
seconds, it doesn't match a valid tm, I wonder if it's possible to do 
"something like" the following:

	1) save the seconds aside
	2) normalize rest of tm struct without seconds
	3) if resulting tm falls inside a gap:
		a) determine the last valid tm before the gap
		b) save the difference (hours, minutes, etc)
		   between our tm and last valid tm aside
	4) using last valid tm or valid resulting tm from above
	   (we'll call this tm1), create another tm (tm2)
	   factoring in the saved seconds
	5) scan the interval between tm1 and tm2 and factor in
	   any leap seconds or additional gaps that that fall
	   between them
	6) add any difference from (3b) above
	7) attempt tm match again & see if we fall into a gap
		a) if so, reject tm
		b) if not, tm is good

I'm sure there's plenty of bugs in this algorithm, but perhaps the idea 
holds merit.

> The C Standard says that mktime can return -1 if attempted in the
> ``spring forward gap'', but it doesn't say how mktime should determine
> whether one is in the gap.

I agree that the standards are vague about how to determine if a tm 
struct is in the gap.  However, it seems clear to me that a tm_sec 
value that adds hours or even days to a tm struct should be considered 
before assuming the time falls between a transition gap.

> Any user program that messes in this area is relying on behavior that
> is not guaranteed by any standard.

True, but regarding "in the gap" handling, the standards do seem to 
lean in the direction of falling back or forward to the previous or 
next valid time.  For example, the VSX4/XPG4 and PCTS test suites 
assume this.  For these standards, item (7b) in algorithm above would 
be replaced with falling back or moving forward according to the value 
of tm_isdst.

> For what it's worth, the GNU C library's mktime agrees with the tz
> mktime on your example, whereas Solaris 2.5.1 and BSD/OS 3.0 have the
> other reasonable interpretation (i.e. both mktime invocations yield
> 575002800).

You can also add DIGITAL UNIX to the 575002800 category above.  Not 
sure about other UNIX flavors.

- Tom