From: Joel C. Salomon <hidden> Date: 2016-06-15 22:49:14
I'd figured to play with Git in an unusual way: to create a repository
for the U.S. Constitution where amendments are presented as patches.
E.g., instead of the First Amendment being placed at the end (as is
usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
Proposed amendments get branches, which get merged in later.
But I'm trying to get the dates right, and I'm missing something. For
example, I made the initial commit with the line
$ git commit --author="The Philadelphia Convention <>" \
--date="Mon, 17 Sep 1787 12:00:00 EST"
but that's not actually setting the commit date to 1787.
Am I doing something wrong, or is Git (quite reasonably) unable to
accept commit dates that far in the past?
--Joel
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:49:14
"Joel C. Salomon" [off-list ref] wrote:
I'd figured to play with Git in an unusual way: to create a repository
for the U.S. Constitution where amendments are presented as patches.
E.g., instead of the First Amendment being placed at the end (as is
usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
Proposed amendments get branches, which get merged in later.
But I'm trying to get the dates right, and I'm missing something. For
example, I made the initial commit with the line
$ git commit --author="The Philadelphia Convention <>" \
--date="Mon, 17 Sep 1787 12:00:00 EST"
but that's not actually setting the commit date to 1787.
Am I doing something wrong, or is Git (quite reasonably) unable to
accept commit dates that far in the past?
Its probably running into problems with time_t on your system being a
32 bit value, and thus having trouble going before some time in 1901.
--
Shawn.
From: Joel C. Salomon <hidden> Date: 2016-06-15 22:49:14
On Mon, Aug 2, 2010 at 2:34 PM, Shawn O. Pearce [off-list ref] wrote:
"Joel C. Salomon" [off-list ref] wrote:
<snip>
quoted
$ git commit --author="The Philadelphia Convention <>" \
--date="Mon, 17 Sep 1787 12:00:00 EST"
but that's not actually setting the commit date to 1787.
Am I doing something wrong, or is Git (quite reasonably) unable to
accept commit dates that far in the past?
Its probably running into problems with time_t on your system being a
32 bit value, and thus having trouble going before some time in 1901.
On Mon, Aug 2, 2010 at 18:32, Joel C. Salomon [off-list ref] wrote:
I'd figured to play with Git in an unusual way: to create a repository
for the U.S. Constitution where amendments are presented as patches.
E.g., instead of the First Amendment being placed at the end (as is
usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
Proposed amendments get branches, which get merged in later.
But I'm trying to get the dates right, and I'm missing something. For
example, I made the initial commit with the line
As noted by Shawn time_t doesn't like ancient commits. But as an aside
I'd like to ask where this project is being hosted. I've wanted to
play with importing law into Git, and it would be interesting to
follow this project.
There's some Icelandic law currently enacted that hasn't been changed
since the 1200s. Getting that into Git would be interesting.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:49:14
"Joel C. Salomon" [off-list ref] writes:
I'd figured to play with Git in an unusual way: to create a repository
for the U.S. Constitution where amendments are presented as patches.
E.g., instead of the First Amendment being placed at the end (as is
usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
Proposed amendments get branches, which get merged in later.
But I'm trying to get the dates right, and I'm missing something. For
example, I made the initial commit with the line
$ git commit --author="The Philadelphia Convention <>" \
--date="Mon, 17 Sep 1787 12:00:00 EST"
but that's not actually setting the commit date to 1787.
Am I doing something wrong, or is Git (quite reasonably) unable to
accept commit dates that far in the past?
Git encodes author and commit (and tagger) time using Unix epoch
(POSIX epoch) plus timezone. As Shawn and Ævar wrote on 32-bit
systems time_t can cover a range of about 136 years in total around
January 1, 1970, which means that the maximum representable time on
32-bit system is 2038-01-19 (the year 2038 problem), but what is more
important to you is that minimum representable time is 1901-12-13.
1787 is too old for 32-bit time_t.
The headers inside commit (and tag) objects are stored in text form,
so they are not limited to 32-bit value. You would have to use system
that has 64-bit time_t, or patch git.
64-bit time_t would be enough for everyone (sic!).
References:
-----------
http://en.wikipedia.org/wiki/Unix_epoch
--
Jakub Narebski
Poland
ShadeHawk on #git
From: Michael J Gruber <hidden> Date: 2016-06-15 22:49:14
Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:
"Joel C. Salomon" [off-list ref] writes:
quoted
I'd figured to play with Git in an unusual way: to create a repository
for the U.S. Constitution where amendments are presented as patches.
E.g., instead of the First Amendment being placed at the end (as is
usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
Proposed amendments get branches, which get merged in later.
But I'm trying to get the dates right, and I'm missing something. For
example, I made the initial commit with the line
$ git commit --author="The Philadelphia Convention <>" \
--date="Mon, 17 Sep 1787 12:00:00 EST"
but that's not actually setting the commit date to 1787.
Am I doing something wrong, or is Git (quite reasonably) unable to
accept commit dates that far in the past?
Git encodes author and commit (and tagger) time using Unix epoch
(POSIX epoch) plus timezone. As Shawn and Ævar wrote on 32-bit
systems time_t can cover a range of about 136 years in total around
January 1, 1970, which means that the maximum representable time on
32-bit system is 2038-01-19 (the year 2038 problem), but what is more
important to you is that minimum representable time is 1901-12-13.
1787 is too old for 32-bit time_t.
The headers inside commit (and tag) objects are stored in text form,
so they are not limited to 32-bit value. You would have to use system
that has 64-bit time_t, or patch git.
Hmm, sizeof(time_t) == 8 for my x86_64 Fedora, but committing ancient
times fails.
My ctime() happily converts negative numbers into dates before the epoch.
I thought the internal representation of our time was "unsigned long", >no?
How can you represent anything before Unix epoch?
We have a mix of time_t and unsigned long (not signed, not long long!),
and we have our own tm_to_time_t() in date.c which explicitly forbids
years before 1970. It seems we don't use standard ctime() and friends
because the standards is not so standard and want to be independent of
that, but sizeof(long) is still system dependent.
Removing the check in tm_to_time_t() by brute force let's me commit
ancient times, but the parser gets them wrong (either on input or on
output, I haven't checked), 1787 ends up output as 1899.
time_t is signed on most systems. Using unsigned long buys us a few
years as long as we don't go through any system routine nor conversion
to time_t. So maybe we should:
- check to make sure we use time_t and system routines only when getting
the current time
- use signed long long as our git_time_t (I think long is less system
dependent then long but I could be wrong)
- make our own algorithms work for the extended format
Michael
On Aug 3, 2010, at 1:55 AM, Michael J Gruber wrote:
Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:
quoted
The headers inside commit (and tag) objects are stored in text form,
so they are not limited to 32-bit value. You would have to use
system
that has 64-bit time_t, or patch git.
64-bit time_t would be enough for everyone (sic!).
time_t is signed on most systems. Using unsigned long buys us a few
years as long as we don't go through any system routine nor conversion
to time_t. So maybe we should:
- check to make sure we use time_t and system routines only when
getting
the current time
- use signed long long as our git_time_t (I think long is less system
dependent then long but I could be wrong)
Obviously you mean "I think long long is less system dependent than
long".
Does any system exist where long long is not 64 bits? In any case,
you can future-proof it by spelling it "int64_t". That symbol is not
guaranteed to exist (nor is <stdint.h>), but neither is the long long
type in the first place.
- make our own algorithms work for the extended format
This would enable systems with 32-bit time_t to deal with pre-1901
commit timestamps in Git.[1] Hopefully such systems will become
increasingly rare.
Josh
[1] Or post-2038 timestamps, but any use case for such is dubious.
From: Jakub Narebski <hidden> Date: 2016-06-15 22:49:14
On Tue, 3 Aug 2010, Michael J Gruber wrote:
Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:
quoted
"Joel C. Salomon" [off-list ref] writes:
quoted
quoted
[...] I'm trying to get the dates right, and I'm missing something. For
example, I made the initial commit with the line
$ git commit --author="The Philadelphia Convention <>" \
--date="Mon, 17 Sep 1787 12:00:00 EST"
but that's not actually setting the commit date to 1787.
Am I doing something wrong, or is Git (quite reasonably) unable to
accept commit dates that far in the past?
Git encodes author and commit (and tagger) time using Unix epoch
(POSIX epoch) plus timezone. As Shawn and Ævar wrote on 32-bit
systems time_t can cover a range of about 136 years in total around
January 1, 1970, which means that the maximum representable time on
32-bit system is 2038-01-19 (the year 2038 problem), but what is more
important to you is that minimum representable time is 1901-12-13.
1787 is too old for 32-bit time_t.
The headers inside commit (and tag) objects are stored in text form,
so they are not limited to 32-bit value. You would have to use system
that has 64-bit time_t, or patch git.
Hmm, sizeof(time_t) == 8 for my x86_64 Fedora, but committing ancient
times fails.
That's because git *porcelain* either does not use time_t consistently,
or has some sanity checks that are good heuristic for ordinary use (like
e.g. commit time not too far in past where git didn't even exists),
or both.
It is not a problem on lowest level, i.e. repository format and plumbing.
I was able to create a commit that had author time before Unix epoch
using plumbing:
1. create an ordinary commit as a template (so I don't have to go down
to the level of gitcore-tutorial:
$ git commit -a
[master 8ddcf60] foo
1 files changed, 1 insertions(+), 0 deletions(-)
2. save commit object in a file, to be edited
$ git cat-file -p HEAD > tmp.txt
3. edit tmp.txt, changing sign of author time
$ [edit tmp.txt]
$ cat tmp.txt
tree 953e0e451fdcb5c21a25ee7ef9faade5791b95ee
parent 6a28c9c996d785b716559f57149a9b5c11fd83ff
author Jakub Narebski [off-list ref] -12808209400 +0200
committer Jakub Narebski [off-list ref] 1280820940 +0200
git-hash-object
4. replace just created commit by handcrafted one
$ git reset --hard HEAD^
$ git hash-object -t commit -w tmp.txt
fa5e5a2b6f27f10ce920ca82ffef07ed3eb3f26f
$ git update-ref -m 'commit: foo' refs/heads/master \
fa5e5a2b6f27f10ce920ca82ffef07ed3eb3f26f
5. check that porcelain parses date correctly
$ git show
commit a5f4eaace56c6887846ea77725e1ac6827bb13b0
Author: Jakub Narebski [off-list ref]
Date: Fri May 31 18:24:20 1929 +0200
git-hash-object
Though when I tried to create commit with authordate further in the past,
porcelain shown 1970 (Unix epoch) as a date, but my system has 32-bit
time_t.
My ctime() happily converts negative numbers into dates before the epoch.
Try ./test-date in git sources...
Junio replied:
quoted
I thought the internal representation of our time was "unsigned long",>no?
How can you represent anything before Unix epoch?
We have a mix of time_t and unsigned long (not signed, not long long!),
and we have our own tm_to_time_t() in date.c which explicitly forbids
years before 1970. It seems we don't use standard ctime() and friends
because the standards is not so standard and want to be independent of
that, but sizeof(long) is still system dependent.
Removing the check in tm_to_time_t() by brute force let's me commit
ancient times, but the parser gets them wrong (either on input or on
output, I haven't checked), 1787 ends up output as 1899.
From: Jeff King <hidden> Date: 2016-06-15 22:49:14
On Tue, Aug 03, 2010 at 02:32:06AM -0700, Joshua Juran wrote:
quoted
- use signed long long as our git_time_t (I think long is less system
dependent then long but I could be wrong)
Obviously you mean "I think long long is less system dependent than
long".
Does any system exist where long long is not 64 bits? In any case,
you can future-proof it by spelling it "int64_t". That symbol is not
guaranteed to exist (nor is <stdint.h>), but neither is the long long
type in the first place.
C99 specifies that "short" and "int" be at least 16 bits, that "long" be
at least 32 bits, and that "long long" be at least 64 bits. See section
5.2.4.2.1.
-Peff
From: Jeff King <hidden> Date: 2016-06-15 22:49:14
On Tue, Aug 03, 2010 at 12:02:52PM +0200, Jakub Narebski wrote:
quoted
Hmm, sizeof(time_t) == 8 for my x86_64 Fedora, but committing ancient
times fails.
That's because git *porcelain* either does not use time_t consistently,
or has some sanity checks that are good heuristic for ordinary use (like
e.g. commit time not too far in past where git didn't even exists),
or both.
It is not a problem on lowest level, i.e. repository format and plumbing.
I was able to create a commit that had author time before Unix epoch
using plumbing:
I am not sure there isn't some unportability at the lowest level. We
freely interchange between time_t and unsigned long in the low-level
date code. It probably happens to work because casting the bits back and
forth between signed and unsigned types generally works, as long as you
end up with the type that you want. But it isn't necessarily portable,
and there can be subtle bugs. See, for example, my recent 9ba0f033.
-Peff
From: Jakub Narebski <hidden> Date: 2016-06-15 22:49:14
On Tue, 3 Aug 2010, Jeff King wrote:
On Tue, Aug 03, 2010 at 12:02:52PM +0200, Jakub Narebski wrote:
quoted
quoted
Hmm, sizeof(time_t) == 8 for my x86_64 Fedora, but committing ancient
times fails.
That's because git *porcelain* either does not use time_t consistently,
or has some sanity checks that are good heuristic for ordinary use (like
e.g. commit time not too far in past where git didn't even exists),
or both.
It is not a problem on lowest level, i.e. repository format and plumbing.
I was able to create a commit that had author time before Unix epoch
using plumbing:
I am not sure there isn't some unportability at the lowest level. We
freely interchange between time_t and unsigned long in the low-level
date code. It probably happens to work because casting the bits back and
forth between signed and unsigned types generally works, as long as you
end up with the type that you want. But it isn't necessarily portable,
and there can be subtle bugs. See, for example, my recent 9ba0f033.
Well, at least there is not a problem at lowest of low, i.e. repository
format level, thanks to the use of textual representation for epoch.
--
Jakub Narebski
Poland
From: Jeff King <hidden> Date: 2016-06-15 22:49:14
On Tue, Aug 03, 2010 at 03:19:09PM +0200, Jakub Narebski wrote:
quoted
I am not sure there isn't some unportability at the lowest level. We
freely interchange between time_t and unsigned long in the low-level
date code. It probably happens to work because casting the bits back and
forth between signed and unsigned types generally works, as long as you
end up with the type that you want. But it isn't necessarily portable,
and there can be subtle bugs. See, for example, my recent 9ba0f033.
Well, at least there is not a problem at lowest of low, i.e. repository
format level, thanks to the use of textual representation for epoch.
Yes, the good news that this is purely a code problem. The data format
is fine. It would just take somebody going through the code and
switching all "unsigned long" to "long long" (or time_t, or even
"gittime_t" if we want to abstract it).
-Peff
From: Michael J Gruber <hidden> Date: 2016-06-15 22:49:14
Jeff King venit, vidit, dixit 03.08.2010 15:20:
On Tue, Aug 03, 2010 at 03:19:09PM +0200, Jakub Narebski wrote:
quoted
quoted
I am not sure there isn't some unportability at the lowest level. We
freely interchange between time_t and unsigned long in the low-level
date code. It probably happens to work because casting the bits back and
forth between signed and unsigned types generally works, as long as you
end up with the type that you want. But it isn't necessarily portable,
and there can be subtle bugs. See, for example, my recent 9ba0f033.
Well, at least there is not a problem at lowest of low, i.e. repository
format level, thanks to the use of textual representation for epoch.
Yes, the good news that this is purely a code problem. The data format
is fine. It would just take somebody going through the code and
switching all "unsigned long" to "long long" (or time_t, or even
"gittime_t" if we want to abstract it).
...and fixing the parser algorithm at least in tm_to_time_t()...
Michael
From: Jeff King <hidden> Date: 2016-06-15 22:49:14
On Tue, Aug 03, 2010 at 03:24:17PM +0200, Michael J Gruber wrote:
quoted
Yes, the good news that this is purely a code problem. The data format
is fine. It would just take somebody going through the code and
switching all "unsigned long" to "long long" (or time_t, or even
"gittime_t" if we want to abstract it).
...and fixing the parser algorithm at least in tm_to_time_t()...
Yeah, I should have been more clear. It is _not_ just "sed s/unsigned
long/long long", but rather checking every change to make sure that you
aren't introducing new bugs, and that the code correctly handles signed
types. Which is why nobody has done it. ;)
-Peff
On Tue, Aug 03, 2010 at 02:32:06AM -0700, Joshua Juran wrote:
quoted
quoted
- use signed long long as our git_time_t (I think long is less
system
dependent then long but I could be wrong)
Obviously you mean "I think long long is less system dependent than
long".
Does any system exist where long long is not 64 bits? In any case,
you can future-proof it by spelling it "int64_t". That symbol is not
guaranteed to exist (nor is <stdint.h>), but neither is the long long
type in the first place.
C99 specifies that "short" and "int" be at least 16 bits, that
"long" be
at least 32 bits, and that "long long" be at least 64 bits. See
section
5.2.4.2.1.
Right, but there's no guarantee that long long won't be *larger* than
64 bits. Though maybe that wouldn't be a problem.
Josh
From: Jeff King <hidden> Date: 2016-06-15 22:49:14
On Tue, Aug 03, 2010 at 10:37:26AM -0700, Joshua Juran wrote:
quoted
quoted
Does any system exist where long long is not 64 bits? In any case,
you can future-proof it by spelling it "int64_t". That symbol is not
guaranteed to exist (nor is <stdint.h>), but neither is the long long
type in the first place.
C99 specifies that "short" and "int" be at least 16 bits, that
"long" be
at least 32 bits, and that "long long" be at least 64 bits. See
section
5.2.4.2.1.
Right, but there's no guarantee that long long won't be *larger* than
64 bits. Though maybe that wouldn't be a problem.
Ah, I took your statement to mean "at least". In this case, I don't
think it would be a problem (we could just represent more times).
-Peff
From: Joel C. Salomon <hidden> Date: 2016-06-15 22:49:14
On 08/02/2010 05:25 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Aug 2, 2010 at 18:32, Joel C. Salomon [off-list ref] wrote:
quoted
I'd figured to play with Git in an unusual way: to create a repository
for the U.S. Constitution where amendments are presented as patches.
E.g., instead of the First Amendment being placed at the end (as is
usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
Proposed amendments get branches, which get merged in later.
I'd like to ask where this project is being hosted. I've wanted to
play with importing law into Git, and it would be interesting to
follow this project.
It's local to my machine for now, especially since I can't (yet?) get
the dates right. Also, I'm rebasing as I tweak the TeX code.
Law-into-RCS has been on my mind since I learned out what RCSs are for.
Read any bill that the US Congress passes: there's an intro, a whole
lot of boilerplate, and then:
SEC. 101. EXTENSION OF CHIP.
Section 2104(a) (42 U.S.C. 1397dd(a)) is amended--
(1) in paragraph (10), by striking ``and'' at the end;
(2) by amending paragraph (11), by striking ``each of
fiscal years 2008 and 2009'' and inserting ``fiscal year
2008''; and
(3) by adding at the end the following new paragraphs:
``(12) for fiscal year 2009, $10,562,000,000;
``(13) for fiscal year 2010, $12,520,000,000;
``(14) for fiscal year 2011, $13,459,000,000;
``(15) for fiscal year 2012, $14,982,000,000; and
``(16) for fiscal year 2013, for purposes of making 2 semi-
annual allotments--
``(A) $3,000,000,000 for the period beginning on
October 1, 2012, and ending on March 31, 2013, and
``(B) $3,000,000,000 for the period beginning on
April 1, 2013, and ending on September 30, 2013.''.
SEC. 102. ALLOTMENTS FOR STATES AND TERRITORIES FOR FISCAL YEARS 2009
THROUGH 2013.
Section 2104 (42 U.S.C. 1397dd) is amended--
(1) in subsection (b)(1), by striking ``subsection (d)''
and inserting ``subsections (d) and (m)'';
(2) in subsection (c)(1), by striking ``subsection (d)''
and inserting ``subsections (d) and (m)(4)''; and
(3) by adding at the end the following new subsection:
....
Sure looks like a patch series to me.
There's some Icelandic law currently enacted that hasn't been changed
since the 1200s. Getting that into Git would be interesting.
Extremely.
I'll put my Constitution project up on GitHub in a few days. Just note
that I *will* rebase and publish.
--Joel
On Wed, Aug 4, 2010 at 16:38, Joel C. Salomon [off-list ref] wrote:
On 08/02/2010 05:25 PM, Ævar Arnfjörð Bjarmason wrote:
quoted
On Mon, Aug 2, 2010 at 18:32, Joel C. Salomon [off-list ref] wrote:
quoted
I'd figured to play with Git in an unusual way: to create a repository
for the U.S. Constitution where amendments are presented as patches.
E.g., instead of the First Amendment being placed at the end (as is
usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
Proposed amendments get branches, which get merged in later.
I'd like to ask where this project is being hosted. I've wanted to
play with importing law into Git, and it would be interesting to
follow this project.
It's local to my machine for now, especially since I can't (yet?) get
the dates right. Also, I'm rebasing as I tweak the TeX code.
Law-into-RCS has been on my mind since I learned out what RCSs are for.
Read any bill that the US Congress passes: there's an intro, a whole
lot of boilerplate, and then:
SEC. 101. EXTENSION OF CHIP.
Section 2104(a) (42 U.S.C. 1397dd(a)) is amended--
(1) in paragraph (10), by striking ``and'' at the end;
(2) by amending paragraph (11), by striking ``each of
fiscal years 2008 and 2009'' and inserting ``fiscal year
2008''; and
(3) by adding at the end the following new paragraphs:
``(12) for fiscal year 2009, $10,562,000,000;
``(13) for fiscal year 2010, $12,520,000,000;
``(14) for fiscal year 2011, $13,459,000,000;
``(15) for fiscal year 2012, $14,982,000,000; and
``(16) for fiscal year 2013, for purposes of making 2 semi-
annual allotments--
``(A) $3,000,000,000 for the period beginning on
October 1, 2012, and ending on March 31, 2013, and
``(B) $3,000,000,000 for the period beginning on
April 1, 2013, and ending on September 30, 2013.''.
SEC. 102. ALLOTMENTS FOR STATES AND TERRITORIES FOR FISCAL YEARS 2009
THROUGH 2013.
Section 2104 (42 U.S.C. 1397dd) is amended--
(1) in subsection (b)(1), by striking ``subsection (d)''
and inserting ``subsections (d) and (m)'';
(2) in subsection (c)(1), by striking ``subsection (d)''
and inserting ``subsections (d) and (m)(4)''; and
(3) by adding at the end the following new subsection:
....
Sure looks like a patch series to me.
Yeah, I think every legal system has their own ad-hoc patch convention
like that. It can be really hard to figure it all out. Parsing that is
non-trivial, but being able to generate diffs based on that would be a
very valuable resource.
quoted
There's some Icelandic law currently enacted that hasn't been changed
since the 1200s. Getting that into Git would be interesting.
Extremely.
I'll put my Constitution project up on GitHub in a few days. Just note
that I *will* rebase and publish.
From: Joel C. Salomon <hidden> Date: 2016-06-15 22:49:15
On 08/04/2010 12:38 PM, Joel C. Salomon wrote:
I'll put my Constitution project up on GitHub in a few days. Just note
that I *will* rebase and publish.
It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
(No amendments yet.)
I'm curious to find out if folks with 64-bit time_t get the correct
author and commit times.
--Joel
On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon [off-list ref] wrote:
On 08/04/2010 12:38 PM, Joel C. Salomon wrote:
quoted
I'll put my Constitution project up on GitHub in a few days. Just note
that I *will* rebase and publish.
It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
(No amendments yet.)
I'm curious to find out if folks with 64-bit time_t get the correct
author and commit times.
On 32bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Wed Dec 31 19:59:59 1969 -0400
On 64bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Mon Sep 17 13:00:00 1787 -0400
It would be useful to turn that into a TODO test for Git.
Heya,
On Thu, Aug 5, 2010 at 16:58, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
On 32bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Wed Dec 31 19:59:59 1969 -0400
On 64bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Mon Sep 17 13:00:00 1787 -0400
It would be useful to turn that into a TODO test for Git.
That's bad, if we can't store a particular date we should do something
about it, not just silently underflow.
--
Cheers,
Sverre Rabbelier
From: Jakub Narebski <hidden> Date: 2016-06-15 22:49:15
Sverre Rabbelier [off-list ref] writes:
On Thu, Aug 5, 2010 at 16:58, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
quoted
On 32bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Wed Dec 31 19:59:59 1969 -0400
On 64bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Mon Sep 17 13:00:00 1787 -0400
It would be useful to turn that into a TODO test for Git.
That's bad, if we can't store a particular date we should do something
about it, not just silently underflow.
We can *store* it without problems, the problem is with
*interpretation* by porcelain (and some plumbing).
--
Jakub Narebski
Poland
ShadeHawk on #git
Heya,
On Fri, Aug 6, 2010 at 03:18, Jakub Narebski [off-list ref] wrote:
We can *store* it without problems, the problem is with
*interpretation* by porcelain (and some plumbing).
That's what I mean though, if the porcelain notices it's trying to
read in a date it can't interpret correctly it should warn the user of
this fact.
--
Cheers,
Sverre Rabbelier
From: Joel C. Salomon <hidden> Date: 2016-06-15 22:49:15
On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon [off-list ref] wrote:
quoted
It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
I'm curious to find out if folks with 64-bit time_t get the correct
author and commit times.
On 32bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Wed Dec 31 19:59:59 1969 -0400
On 64bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Mon Sep 17 13:00:00 1787 -0400
Cool, it works! (The 13:00 should have been 12:00, but there's some
DST weirdness at work.)
Can you check what git-fsck has to say about the repos, on 32- &
64-bit machines?
--Joel
On Fri, Aug 6, 2010 at 15:18, Joel C. Salomon [off-list ref] wrote:
On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon [off-list ref] wrote:
quoted
It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
I'm curious to find out if folks with 64-bit time_t get the correct
author and commit times.
On 32bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Wed Dec 31 19:59:59 1969 -0400
On 64bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Mon Sep 17 13:00:00 1787 -0400
Cool, it works! (The 13:00 should have been 12:00, but there's some
DST weirdness at work.)
Can you check what git-fsck has to say about the repos, on 32- &
64-bit machines?
32bit says:
error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid
author/committer line
64 bit doesn't give any warning at all.
From: Joel C. Salomon <hidden> Date: 2016-06-15 22:49:15
On Fri, Aug 6, 2010 at 11:19 AM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
On Fri, Aug 6, 2010 at 15:18, Joel C. Salomon [off-list ref] wrote:
quoted
Can you check what git-fsck has to say about the repos, on 32- &
64-bit machines?
32bit says:
error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid
author/committer line
64 bit doesn't give any warning at all.
Meanwhile, on Fri, Aug 6, 2010 at 11:08 AM, Sverre Rabbelier
[off-list ref] wrote:
On Fri, Aug 6, 2010 at 03:18, Jakub Narebski [off-list ref] wrote:
quoted
We can *store* it without problems, the problem is with
*interpretation* by porcelain (and some plumbing).
That's what I mean though, if the porcelain notices it's trying to
read in a date it can't interpret correctly it should warn the user of
this fact.
Seems the error can be checked for when you ask, but I'd rather not
have git complain every time I use constitution.git.
Aside: I generated the time stamps with
<http://github.com/schwern/y2038>, which may be useful for
cross-platform y2038 fixes.
--Joel
On Fri, Aug 6, 2010 at 15:18, Joel C. Salomon [off-list ref] wrote:
quoted
On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon [off-list ref] wrote:
quoted
It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
I'm curious to find out if folks with 64-bit time_t get the correct
author and commit times.
On 32bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Wed Dec 31 19:59:59 1969 -0400
On 64bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Mon Sep 17 13:00:00 1787 -0400
Cool, it works! (The 13:00 should have been 12:00, but there's some
DST weirdness at work.)
Can you check what git-fsck has to say about the repos, on 32- &
64-bit machines?
32bit says:
error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid
author/committer line
64 bit doesn't give any warning at all.
I don't think you're using the latest git.
I get this on 64 bit:
error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid author/committer line - bad date
This is triggered by the negative sign '-' in front of the time
field which is not one of 0123456789. See fsck.c line 244.
-brandon
On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon [off-list ref] wrote:
quoted
It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
I'm curious to find out if folks with 64-bit time_t get the correct
author and commit times.
On 32bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Wed Dec 31 19:59:59 1969 -0400
On 64bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Mon Sep 17 13:00:00 1787 -0400
Cool, it works! (The 13:00 should have been 12:00, but there's some
DST weirdness at work.)
Something other than the fact that -0400 should be -0500?
Or are you talking about an issue with the software you are using to
create the dates?
-brandon
On Fri, Aug 6, 2010 at 16:00, Brandon Casey
[off-list ref] wrote:
Ævar Arnfjörð Bjarmason wrote:
quoted
On Fri, Aug 6, 2010 at 15:18, Joel C. Salomon [off-list ref] wrote:
quoted
On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon [off-list ref] wrote:
quoted
It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
I'm curious to find out if folks with 64-bit time_t get the correct
author and commit times.
On 32bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Wed Dec 31 19:59:59 1969 -0400
On 64bit:
commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date: Mon Sep 17 13:00:00 1787 -0400
Cool, it works! (The 13:00 should have been 12:00, but there's some
DST weirdness at work.)
Can you check what git-fsck has to say about the repos, on 32- &
64-bit machines?
32bit says:
error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid
author/committer line
64 bit doesn't give any warning at all.
I don't think you're using the latest git.
Guilty as charged. It's a Debian 1.7.1 git.
I get this on 64 bit:
error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid author/committer line - bad date
This is triggered by the negative sign '-' in front of the time
field which is not one of 0123456789. See fsck.c line 244.
-brandon
On Aug 7, 2010, at 8:46 PM, Joel C. Salomon wrote:
On 08/06/2010 12:44 PM, Brandon Casey wrote:
quoted
Joel C. Salomon wrote:
quoted
Cool, it works! (The 13:00 should have been 12:00, but there's some
DST weirdness at work.)
Something other than the fact that -0400 should be -0500?
No, that's probably it; I'd overlooked the time-zone specifier.
Thanks.
Daylight Saving Time wasn't adopted in the US until 1918, so all
Eastern times before then should be displayed as -500, regardless of
the time of year.
http://en.wikipedia.org/wiki/Daylight_saving_time
Josh