Am 28.02.2017 um 21:54 schrieb Johannes Schindelin:
Hi Junio,
On Tue, 28 Feb 2017, Junio C Hamano wrote:
René Scharfe <l.s.r@xxxxxx> writes:
Am 28.02.2017 um 15:28 schrieb Jeff King:
It looks from the discussion like the sanest path forward is our own
signed-64bit timestamp_t. That's unfortunate compared to using the
standard time_t, but hopefully it would reduce the number of knobs
(like TIME_T_IS_INT64) in the long run.
Glibc will get a way to enable 64-bit time_t on 32-bit platforms
eventually (https://sourceware.org/glibc/wiki/Y2038ProofnessDesign).
Can platforms that won't provide a 64-bit time_t by 2038 be actually
used at that point? How would we get time information on them? How
would a custom timestamp_t help us?
That's a sensible "wait, let's step back a bit". I take it that you are
saying "time_t is just fine", and I am inclined to agree.
Right now, they may be able to have future timestamps ranging to
year 2100 and switching to time_t would limit their ability to
express future time to 2038 but they would be able to express
timestamp in the past to cover most of 20th century. Given that
these 32-bit time_t software platforms will die off before year 2038
(either by underlying hardware getting obsolete, or software updated
to handle 64-bit time_t), the (temporary) loss of 2038-2100 range
would not be too big a deal to warrant additional complexity.
You seem to assume that time_t is required to be signed. But from my
understanding that is only guaranteed by POSIX, not by ISO C.
We may very well buy ourselves a ton of trouble if we decide to switch to
`time_t` rather than to `int64_t`.
True, and time_t doesn't even have to be an integer type. But which
platforms capable of running git use something else than int32_t or int64_t?
René