[...] > > > as we > > > haven't crossed the 2038 boundary yet, > > > > Which isn't far away anymore and we're only a few > years away until > > (government) customers are going to require some of > kind Y2039 > > compilance. > > Few, but many enough that it'll by my kids' problem. > ;-} [...]
Not relevant to filesystem objects (or to stat()) yet, but consider those dealing with for example 30-year mortgages; they already have to deal with dates past 2038. Presumably those are most often represented by some database field not subject to the difficulties of a 32-bit time_t, but still, that seems like avoiding the problem rather than responding to it. (But I do wonder that given the rationale for difftime(3c) why there isn't a complementary function to add an offset toba time, such that (aside from overflows) func(time0,difftime(time1, time0)) == time1 Ideally such a function would try to detect wraparounds and such and either raise a signal in case of problems or take a pointer as a 3rd arg so that one of return value and what that 3rd arg points to could be the result and the other could be the status (since all result values could be legal, so one of them makes a good choice as an error indicator). I have a sneaking suspicion that the reason this wasn't provided was that it was understood that there were all sorts of land mines lying around with respect to past or future time_t values, and that a means of creating such values without waiting for the problem to arise on its own was therefore being avoided.) I imagine that if there are still reasons to have 32-bit executables as 2038 gets enough closer, solutions would still be possible, although the less ugly ones might at a minimum (for programs that didn't care about the size of a time_t in terms of storage or memory use or data structure layout) require a recompile. -- This message posted from opensolaris.org
