Re: [PATCH] Accept dates before 2000/01/01 when specified as seconds since the epoch

I vaguely recall hitting the same issue soon after date.c was
done, and sending in a patch in the same spirit but with
different implementation (I essentially duplicated that "seconds
since epoch" without any cutoff as the last ditch fallback) long
time ago (this was before I took git over; the patch was rejected).

It almost makes me wonder if it is better to introduce a special
syntax to denote "seconds since epoch plus timezone offset" for
our Porcelain use, instead of keeping this arbitrary cut-off
date which nobody can agree on and which forces us to roll back
from time to time.  For one thing, such a syntax would allow us
to talk about a timestamp before the epoch.

Perhaps

	"epoch" [-+] [0-9]+ " " [-+][0-9][0-9][0-9][0-9]

?

Junio C Hamano wrote:

I vaguely recall hitting the same issue soon after date.c was
done, and sending in a patch in the same spirit but with
different implementation (I essentially duplicated that "seconds
since epoch" without any cutoff as the last ditch fallback) long
time ago (this was before I took git over; the patch was rejected).

It almost makes me wonder if it is better to introduce a special
syntax to denote "seconds since epoch plus timezone offset" for
our Porcelain use, instead of keeping this arbitrary cut-off
date which nobody can agree on and which forces us to roll back
from time to time.  For one thing, such a syntax would allow us
to talk about a timestamp before the epoch.

Perhaps

        "epoch" [-+] [0-9]+ " " [-+][0-9][0-9][0-9][0-9]

?

OTOH, the previous limit 2000/01/01 was completely arbitrary, while the
new limit 100000000secs has some justification: Numbers with fewer
digits could be mistaken as dates.

-- Hannes

Junio C Hamano wrote:

I vaguely recall hitting the same issue soon after date.c was
done, and sending in a patch in the same spirit but with
different implementation (I essentially duplicated that "seconds
since epoch" without any cutoff as the last ditch fallback) long
time ago (this was before I took git over; the patch was rejected).

It almost makes me wonder if it is better to introduce a special
syntax to denote "seconds since epoch plus timezone offset" for
our Porcelain use, instead of keeping this arbitrary cut-off
date which nobody can agree on and which forces us to roll back
from time to time.  For one thing, such a syntax would allow us
to talk about a timestamp before the epoch.

Perhaps

	"epoch" [-+] [0-9]+ " " [-+][0-9][0-9][0-9][0-9]

Probably a good idea, though it would break cg-admin-rewritehist.  I had
to make a similar change when working with the Perl history.  Perhaps
allow both?

There is a 10 digit ISO forms (YYYYMMDDHH) and a 9 digit form
(YYYYDDDHH), but these are very rare :)

Sam.

Hi,

On Thu, 7 Jun 2007, Sam Vilain wrote:

Junio C Hamano wrote:

quoted

I vaguely recall hitting the same issue soon after date.c was
done, and sending in a patch in the same spirit but with
different implementation (I essentially duplicated that "seconds
since epoch" without any cutoff as the last ditch fallback) long
time ago (this was before I took git over; the patch was rejected).

It almost makes me wonder if it is better to introduce a special
syntax to denote "seconds since epoch plus timezone offset" for
our Porcelain use, instead of keeping this arbitrary cut-off
date which nobody can agree on and which forces us to roll back
from time to time.  For one thing, such a syntax would allow us
to talk about a timestamp before the epoch.

Perhaps

	"epoch" [-+] [0-9]+ " " [-+][0-9][0-9][0-9][0-9]

Probably a good idea, though it would break cg-admin-rewritehist.

FWIW I don't think we have to care that much about cg-admin-rewritehist, 
since it lives on as git-filter-branch, and we can adapt it as we go.

Ciao,
Dscho