Robert Elz <kre@munnari.oz.au> writes:
it is entirely reasonable to run a program (for every year data is being generated) to calculate Israeli -> Gregorian conversions.
I agree with much of your analysis, but this point might require some further thought. It is entirely reasonable run a program for 32-bit time_t, since we need to generate predictions for future conversions only out to the year 2038. It isn't necessarily reasonable to do it for 64-bit time_t, since (in theory, anyway) we'd need to generate preductions for future conversions out to the year 292,277,026,596 or so, assuming I've done the arithmetic right. This number is a bit silly since it exceeds the commonly predicted useful life of the universe, but the point is that we'll have to arbitrarily cut off our predictions somewhere (e.g., 100 years in the future), and any arbitrary cutoff will be a bit of a pain. For example, suppose we arbitrarily cut off 100 years into the future. Do we need to generate new tables every year, as the cutoff time advances? This may sound like a trivial issue but in practice trivial issues like these build up.
If you're going to have a very wide allowable range, putting some limits on what gets converted makes sense. Pretending we know how times and calendars will be done for thousands of years into the future is absurd,
But unfortunately it is required for POSIX compliance, at least if tm_year is representable as an int (true for years up to about 2**31 on most hosts) and if TZ uses the POSIX format.
Backwards, 1970 is far enough to be accurate.
Here I think you're being a bit too modest in aim. The existing code already works for dates back to 1901 (in 32-bit time_t), and some people already rely on this, to handle time stamps the elderly (medical records, horoscopes, etc.). I don't see any technical reason to remove support for that. I'd say we might as well go back at least to the introduction of standard time (circa 1850), for time_t wide enough to support that. I don't see any fundamental technical objection to going back that far.