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.
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.
Don't you think these two things might be related?
Also: https://www.theregister.co.uk/2001/09/14/downs_syndrome_scre...
In particular, 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 has a history of French law)
Tom Scott has a pretty good video explaining exactly why writing code about time is not trivial:
The Problem with Time & Timezones - Computerphile
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.
But it might be a good idea in general, and then it would solve this issue as a side effect.
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.
IBM, Siemens, Texas Instruments, that's it of the top of my head. Anyone else?
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.