3 ms·

The fact that GitHub marks the initial commits as 2016, and says 48 years ago when you click on one, even though it clearly says 1787 in the commit message make

by shpx 7y ago

The fact that GitHub marks the initial commits as 2016, and says 48 years ago when you click on one, even though it clearly says 1787 in the commit message makes me sad. All these 6 figure salaries and we still can't write code that handles dates. How does someone look at a date and think it should only have two digits? How's it possible that someone could look at a system that only stores enough time for 68 years in future and think that's fine? Why is so much code written with the assumption that a year is a four digit number? The passage of time is guaranteed and yet programmers are somehow constantly surprised that it happens. The world is 14 billion years old and will exist for much much longer. Someone might need to write code dealing with any of those time periods, why do we make them expend mental effort on (what should be) such a reasonable, trivial task? We have the bits to spare. It's a strange form of collective procrastination.

zifnab06 7y ago
Github is primarily Rails/MySQL (or was last time I paid attention to any of their blogs), I'm guessing they're storing dates as a TIMESTAMP and not a DATETIME (4 bytes vs 8 bytes). GitHub's BigQuery public data set has 234,759,841 unique commits, and it appears there's 2 dates per commit (author and committer dates). So an extra ~1.8GB per master/shard group. Entirely doable but I have no idea what their scale actually is or how that translates to network throughput or anything else really.
jeromebaek 7y ago
Something about your comment rubs me the wrong way, and I think it’s a kind of toxic idealism that doesn’t acknowledge how software isn’t a mathematical object but situated in the real world. You realize 48 years ago is the Unix epoch? Circumventing this problem to admit commits that were made before 1970, which clearly has no real world use case, is over engineering at its worst. Similarly, with designing a system to last longer than 68 years. The number of tech companies that have lasted more than 68 years can be counted on one hand.
- eru 7y ago
  It would be overkill to move from 32 bits of Unix timestamps to 64 bit signed ints just for this application. But it might be a good idea in general, and then it would solve this issue as a side effect.
  - jeromebaek 7y ago
    Sure, but that’s a problem way down the stack, a problem for language designers, not application developers.
    - eru 7y ago
      Well, they are also getting six figure salaries. But in any case, eg Python supports dates before 1970 just fine. It was a conscious decision by the application developers of git to restrict themselves to whatever C has to offer.
- gdy 7y ago
  The word 'toxic' is toxic.
- TeMPOraL 7y ago
  And then you wonder why our technology is a pile of garbage built on top of a steaming pile of half-composted garbage, always breaking, and why a good chunk of software jobs consist mostly or solely of keeping it from falling apart. What's toxic is being penny-wise, pound-foolish repeatedly, at the scale of the industry.
- Torwald 7y ago
  > The number of tech companies that have lasted more than 68 years can be counted on one hand. IBM, Siemens, Texas Instruments, that's it of the top of my head. Anyone else?
enhdless 7y ago
> such a reasonable, trivial task? Tom Scott has a pretty good video explaining exactly why writing code about time is not trivial: The Problem with Time & Timezones - Computerphile https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
seanmcdirmid 7y ago
Wasn’t the epoch 48 years ago? Wait, the epoch was 49 years ago, so that isn’t it.
z3t4 7y ago
I guess people have forgotten about the year 2k problem, where nuclear power-plants where to explode, nuclear missiles was to fire, the world would end, because the year would be reset from 99 to 00. A lot of resources was put to fix it. And when the millennium finally changed, nothing really happened. That said, I cringe every time I see a date problem presented in a work interview or challenge. Like how to calculate the first Monday in a set year. Because I have done exactly that, professionally. And as the years went by - edge case over edge case showed up, making me rewrite the formula. So dates are non-trivial. You probably know there are leap years, but did you also know there are leap seconds ? So beware of that when you implement that time critical database redundancy and replication system.
- sincerely 7y ago
  > A lot of resources was put to fix it. And when the millennium finally changed, nothing really happened. Don't you think these two things might be related? Also: https://www.theregister.co.uk/2001/09/14/downs_syndrome_screening_failures_linked/ https://www.theregister.co.uk/2001/09/14/downs_syndrome_scre...
  - z3t4 7y ago
    100 year olds are probably still receiving baby products, etc
- dmix 7y ago
  Datetimes are easily in the top ten most annoying parts of programming.
- xfkechyk 7y ago
  relevant podcast: https://www.stitcher.com/podcast/headlong-surviving-y2k https://www.stitcher.com/podcast/headlong-surviving-y2k
Someone 7y ago
https://stackoverflow.com/questions/21787872/is-it-possible-to-set-a-git-commit-to-have-a-timestamp-prior-to-1970 https://stackoverflow.com/questions/21787872/is-it-possible-... seems to indicate it should be possible now. In particular, https://stackoverflow.com/a/24977895 https://stackoverflow.com/a/24977895 says: ”As I mentioned in 2017, in "Use future date while making git commits", Git has started to adopt a different and dedicated timestamp_t type. As illustrated in Legilibre/Archeo-Lex issue 47: Dates are now using the timestamp_t type, defined as typedef uintmax_t timestamp_t;, in place of unsigned long type, in order to fix some issues on 32bits platforms... and Windows 64 bits ^^. The project archeo-lex.fr (which depends on older dates) is using git hash-object, combined with the Git repo viewer Legilibre/Archeo-Lex-web. This is now (Feb. 2019) done, as commented by Seb35“ (https://archeo-lex.fr/codes https://archeo-lex.fr/codes has a history of French law)
- jwilk 7y ago
  It's still unsigned, so I don't see how it helps with pre-1970 dates.
he_the_great 7y ago
Git does not store commit dates pre 1971. The commit message has the correct date because it is just text.

by shpx 7y ago

zifnab06 7y ago

Github is primarily Rails/MySQL (or was last time I paid attention to any of their blogs), I'm guessing they're storing dates as a TIMESTAMP and not a DATETIME (4 bytes vs 8 bytes). GitHub's BigQuery public data set has 234,759,841 unique commits, and it appears there's 2 dates per commit (author and committer dates). So an extra ~1.8GB per master/shard group. Entirely doable but I have no idea what their scale actually is or how that translates to network throughput or anything else really.

jeromebaek 7y ago

Something about your comment rubs me the wrong way, and I think it’s a kind of toxic idealism that doesn’t acknowledge how software isn’t a mathematical object but situated in the real world. You realize 48 years ago is the Unix epoch? Circumventing this problem to admit commits that were made before 1970, which clearly has no real world use case, is over engineering at its worst. Similarly, with designing a system to last longer than 68 years. The number of tech companies that have lasted more than 68 years can be counted on one hand.

eru 7y ago
It would be overkill to move from 32 bits of Unix timestamps to 64 bit signed ints just for this application. But it might be a good idea in general, and then it would solve this issue as a side effect.
- jeromebaek 7y ago
  Sure, but that’s a problem way down the stack, a problem for language designers, not application developers.
  - eru 7y ago
    Well, they are also getting six figure salaries. But in any case, eg Python supports dates before 1970 just fine. It was a conscious decision by the application developers of git to restrict themselves to whatever C has to offer.
gdy 7y ago
The word 'toxic' is toxic.
TeMPOraL 7y ago
And then you wonder why our technology is a pile of garbage built on top of a steaming pile of half-composted garbage, always breaking, and why a good chunk of software jobs consist mostly or solely of keeping it from falling apart. What's toxic is being penny-wise, pound-foolish repeatedly, at the scale of the industry.
Torwald 7y ago
> The number of tech companies that have lasted more than 68 years can be counted on one hand. IBM, Siemens, Texas Instruments, that's it of the top of my head. Anyone else?

enhdless 7y ago

> such a reasonable, trivial task? Tom Scott has a pretty good video explaining exactly why writing code about time is not trivial: The Problem with Time & Timezones - Computerphile https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY

seanmcdirmid 7y ago

Wasn’t the epoch 48 years ago? Wait, the epoch was 49 years ago, so that isn’t it.

z3t4 7y ago

I guess people have forgotten about the year 2k problem, where nuclear power-plants where to explode, nuclear missiles was to fire, the world would end, because the year would be reset from 99 to 00. A lot of resources was put to fix it. And when the millennium finally changed, nothing really happened. That said, I cringe every time I see a date problem presented in a work interview or challenge. Like how to calculate the first Monday in a set year. Because I have done exactly that, professionally. And as the years went by - edge case over edge case showed up, making me rewrite the formula. So dates are non-trivial. You probably know there are leap years, but did you also know there are leap seconds ? So beware of that when you implement that time critical database redundancy and replication system.

sincerely 7y ago
> A lot of resources was put to fix it. And when the millennium finally changed, nothing really happened. Don't you think these two things might be related? Also: https://www.theregister.co.uk/2001/09/14/downs_syndrome_screening_failures_linked/ https://www.theregister.co.uk/2001/09/14/downs_syndrome_scre...
- z3t4 7y ago
  100 year olds are probably still receiving baby products, etc
dmix 7y ago
Datetimes are easily in the top ten most annoying parts of programming.
xfkechyk 7y ago
relevant podcast: https://www.stitcher.com/podcast/headlong-surviving-y2k https://www.stitcher.com/podcast/headlong-surviving-y2k

Someone 7y ago

https://stackoverflow.com/questions/21787872/is-it-possible-to-set-a-git-commit-to-have-a-timestamp-prior-to-1970 https://stackoverflow.com/questions/21787872/is-it-possible-... seems to indicate it should be possible now. In particular, https://stackoverflow.com/a/24977895 https://stackoverflow.com/a/24977895 says: ”As I mentioned in 2017, in "Use future date while making git commits", Git has started to adopt a different and dedicated timestamp_t type. As illustrated in Legilibre/Archeo-Lex issue 47: Dates are now using the timestamp_t type, defined as typedef uintmax_t timestamp_t;, in place of unsigned long type, in order to fix some issues on 32bits platforms... and Windows 64 bits ^^. The project archeo-lex.fr (which depends on older dates) is using git hash-object, combined with the Git repo viewer Legilibre/Archeo-Lex-web. This is now (Feb. 2019) done, as commented by Seb35“ (https://archeo-lex.fr/codes https://archeo-lex.fr/codes has a history of French law)

jwilk 7y ago
It's still unsigned, so I don't see how it helps with pre-1970 dates.

he_the_great 7y ago

Git does not store commit dates pre 1971. The commit message has the correct date because it is just text.