Re: Y2K is long gone. Time to deprecate time.c?

[Hans-Bernhard B. <HBB...@t-...>]

Ethan Merritt wrote:

> ggmtime() stupidly calculates time by incremental subtraction from a
> target date given in seconds.  If the target date is large, say
> 10^12, a single call can take a minute to return.

Hmm... what platforms take a minute to do about ten thousand subtractions?

Calendars are remarkably tricky to get right, and that algorithm, while 
it may look clumsy at first, at least gets the job done correctly.  Many 
have come up with much worse results.

> If the target date is even larger, say 10^38, it would take 
> approximately 10^22 years to return from a single date calculation.

Actually it would be even worse.  Starting off at 1e38, it would take
literally forever, because subtracting 3e7 from 1e38 will not have any
effect at all, on the vast majority of platforms available right now. 
Greetings from the round-off department.

> The thing is, the routines in time.c are marked in the header as 
> being protection against possible Y2K problems in the POSIX time 
> routines provided by a system library.  Their use is under the
> control of USE_SYSTEM_TIME, which currently defaults to being
> undefined.

The problem is that this not only currently defaults to being undefined, 
but rather it has always been deactivated.  The USE_SYSTEM_TIME version 
of the code has been sitting unused and ignored, for over a decade. 
Just turning it on now would be risky, to say the least.

> If not that, should we put a sanity check in the time routines 
> limiting the accessible future to, say, the first 1.e10 seconds of
> the epoch?

That might be prudent, indeed. :-)

Oh, and lest we forget: deprecating time.c can not be the goal --- we'll 
keep needing at least the implementation in the USE_SYSTEM_TIME parts of 
it, to do the mapping between POSIX' and our own epoch, and between 
time_t and doubles.