To avoid failed tests on systems with a 32-bit time_t, you should either make the tests for time_t values >=2^31 conditional on the width of time_t, or they should be changed to avoid testing beyond 2038?
I think the question is if we should assume that the platforms will be fixed, if we should write a workaround for those platforms, or if we should drop support for those platforms. I don't think dropping the to-be-broken pike functions is an alternative, given how central they are.
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
I think the question is if we should assume that the platforms will be fixed, if we should write a workaround for those platforms, or if we should drop support for those platforms. I don't think dropping the
The only sane workaround would seem to be that if the libc mktime() cannot handle it, we fall back on Calendar. Anything else would be a disaster waiting to happen with respect to daylight saving time after 2038.
Stephen R. van den Berg wrote:
Martin Nilsson (Coppermist) @ Pike (-) developers forum wrote:
I think the question is if we should assume that the platforms will be fixed, if we should write a workaround for those platforms, or if we should drop support for those platforms. I don't think dropping the
The only sane workaround would seem to be that if the libc mktime() cannot handle it, we fall back on Calendar. Anything else would be a disaster waiting to happen with respect to daylight saving time after 2038.
There is an interesting feedback loop from Calendar back to localtime() though, so that needs to be tied down before this can work.
pike-devel@lists.lysator.liu.se
-
Martin Nilsson (Coppermist) ＠ Pike (-) developers forum -
Stephen R. van den Berg