However, at this point, the general decision about "time_t" on NetBSD
   is that it "should be" a 32-bit quantity, even on LP64 ports.  (Until
   that is, it's updated across the board to something else.) As far as I
   know, the sparc64 violates that...
   
   As far as I'm concerned, you have two things to fix, and indeed, if
   you'd done the right thing with time_t months and months ago, wouldn't
   have had the on-disk structure problem now.



sparc64 is not currently broken.  it was *way* back, but you and jason
made me change time_t to be 32 bits.  eeh is dealing with the fact that
on 64 bit solaris, time_t is 64 bits.


.mrg.


(honestly, i still don't see why sparc64 has to pay the penalty of using
a 32 bit time_t but as you said, that iswas the "general decision" about
time_t in NetBSD.  and changing it back now is not really feasible.)