Re: [PATCH 0/6] Use time_t

Jeff King writes: > On Tue, Feb 28, 2017 at 02:27:22PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > ... We can certainly stick with it for now (it's awkward if you >> > really do have an entry on Jan 1 1970, but other than that it's an OK >> >

Re: [PATCH 0/6] Use time_t

Am 28.02.2017 um 21:54 schrieb Johannes Schindelin: Hi Junio, On Tue, 28 Feb 2017, Junio C Hamano wrote: René Scharfe 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

Re: [PATCH 0/6] Use time_t

Am 01.03.2017 um 00:10 schrieb Johannes Schindelin: Hi René, On Tue, 28 Feb 2017, René Scharfe wrote: Am 28.02.2017 um 21:54 schrieb Johannes Schindelin: On Tue, 28 Feb 2017, Junio C Hamano wrote: René Scharfe writes: Am 28.02.2017 um 15:28 schrieb Jeff King: It looks

Re: [PATCH 0/6] Use time_t

Jeff King writes: > ... We can certainly stick with it for now (it's awkward if you > really do have an entry on Jan 1 1970, but other than that it's an OK > marker). I agree that the most negatively value is probably a saner > choice, but we can switch to it after the dust

Re: [PATCH 0/6] Use time_t

Hi René, On Tue, 28 Feb 2017, René Scharfe wrote: > Am 28.02.2017 um 21:54 schrieb Johannes Schindelin: > > > > On Tue, 28 Feb 2017, Junio C Hamano wrote: > > > > > René Scharfe writes: > > > > > > > Am 28.02.2017 um 15:28 schrieb Jeff King: > > > > > > > > > It looks from the

Re: [PATCH 0/6] Use time_t

On Tue, Feb 28, 2017 at 02:27:22PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > ... We can certainly stick with it for now (it's awkward if you > > really do have an entry on Jan 1 1970, but other than that it's an OK > > marker). I agree that the most negatively value

Re: [PATCH 0/6] Use time_t

On Tue, Feb 28, 2017 at 09:54:58PM +0100, Johannes Schindelin wrote: > > 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

Re: [PATCH 0/6] Use time_t

Hi Junio, On Tue, 28 Feb 2017, Junio C Hamano wrote: > René Scharfe 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 > >>

Re: [PATCH 0/6] Use time_t

On Tue, Feb 28, 2017 at 10:55:49AM -0800, Junio C Hamano wrote: > > 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

Re: [PATCH 0/6] Use time_t

On Tue, Feb 28, 2017 at 09:26:23AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I do not just agree, but I think the move to a signed timestamp is a big > > improvement. Git's object format is happy to represent times before > > 1970, but the code is not. I know this

Re: [PATCH 0/6] Use time_t

René Scharfe 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

Re: [PATCH 0/6] Use time_t

Jeff King writes: > I do not just agree, but I think the move to a signed timestamp is a big > improvement. Git's object format is happy to represent times before > 1970, but the code is not. I know this has been a pain for people who > import ancient histories into Git. > > It

Re: [PATCH 0/6] Use time_t

Am 28.02.2017 um 15:28 schrieb Jeff King: On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote: One notable fallout of this patch series is that on 64-bit Linux (and other platforms where `unsigned long` is 64-bit), we now limit the range of dates to LONG_MAX (i.e. the *signed*

Re: [PATCH 0/6] Use time_t

Hi Peff, On Tue, 28 Feb 2017, Jeff King wrote: > On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote: > > > One notable fallout of this patch series is that on 64-bit Linux (and > > other platforms where `unsigned long` is 64-bit), we now limit the > > range of dates to LONG_MAX

Re: [PATCH 0/6] Use time_t

On Mon, Feb 27, 2017 at 10:30:20PM +0100, Johannes Schindelin wrote: > One notable fallout of this patch series is that on 64-bit Linux (and > other platforms where `unsigned long` is 64-bit), we now limit the range > of dates to LONG_MAX (i.e. the *signed* maximum value). This needs to be > done

Re: [PATCH 0/6] Use time_t

Hi Junio, On Mon, 27 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > One notable fallout of this patch series is that on 64-bit Linux (and > > other platforms where `unsigned long` is 64-bit), we now limit the > > range of dates to LONG_MAX (i.e.

Re: [PATCH 0/6] Use time_t

Johannes Schindelin writes: > One notable fallout of this patch series is that on 64-bit Linux (and > other platforms where `unsigned long` is 64-bit), we now limit the range > of dates to LONG_MAX (i.e. the *signed* maximum value). This needs to be > done as `time_t`

[PATCH 0/6] Use time_t

Git v2.9.2 was released in a hurry to accomodate for platforms like Windows, where the `unsigned long` data type is 32-bit even for 64-bit setups. The quick fix was to simply disable all the testing with "absurd" future dates. However, we can do much better than that, as `time_t` exists, and at