> Changing this is would involve including independent date
> routines which don't
> have this restriction. I did start on this some time ago but other higher
> priority tasks (e.g. paid ones!) took over.
I've got 64-bit date/time routines that are good out to 2270 that work fine
on 32-bit architectures. Would the following routines be sufficient:
1) All routines are based on a uint64_t to hold the seconds since the epoch.
So you can still easily convert to/from time_t for in-range values.
2) Get day, month, year, hour, minute, and second from a uint64_t seconds
since the epoch value. Or, convert a uint64_t to a struct tm (as either UTC
or local time) and you can extract whichever of these elements are needed.
3) Convert to time_t, which returns an error if the value is out of range.
4) Format a uint64_t in UTC time using a strftime like format. Format in
local time using a strftime like format.
5) Convert a struct tm in either local or UTC time to a 64-bit 'seconds
since epoch' value.
To add a second or a week or compare two times, normal integer routines can
be used. All routines, again, are believed valid from the epoch to 2270. (At
worst, they might somehow bungle leap year issues, I guess.)
The way these routines work is for out-of-range dates, they fudge them into
range (using an offset that keeps all time rules the same), use the system
routines, and then fudge them back to the starting range.
For example (this is not quite the actual code):
#define ULL(x) x##ULL
#define SSE(x,y) if(secs>=x) { secs-=x; add_years=y; }
#define DAYS(x) (ULL(x)*(24*60*60))
...
// adjust to range
if(secs<ULL(0x7fffffff)) { add_years=0; }
else SSE(DAYS(87669), 240) else SSE(DAYS(80353), 220)
else SSE(DAYS(73049), 200) else SSE(DAYS(65744), 180)
else SSE(DAYS(58439), 160) else SSE(DAYS(51134), 140)
else SSE(DAYS(43830), 120) else SSE(DAYS(36525), 100)
else SSE(DAYS(29220), 80) else SSE(DAYS(23376), 64)
...
// bring it back in range
t.tm_year+=add_years;
If this code would be helpful, I could clean it up and separate it from some
other code it's entangled with. I don't have the time to work on integrating
it with OpenSSL though. (Though if there's interest but not resources, I
might be able to task someone else with doing it.)
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
