On Fri, Aug 02, 2024 at 11:46:30AM +0200, the.tester@xxxxxxx wrote: > To me, the error message is at least misleading. > It also seem to be hidin the underlying issue that git (commit) > doesn’t accept time stamps before the epoch. > > Given that 1970-01-01 00:00:00 seems to be the lower boundary, I > expected some time in 2038-01-19 to be the corresponding upper > boundary. We use an unsigned value (hence the lower bound being at the epoch), so in a 32-bit world the high boundary would be 2106. But we actually use uintmax_t these days, so it's effectively infinite (even no 32-bit systems, there should be _some_ larger type available). But... > However the same error message is given when the date is >= 2100-01-01 > 00:00:00. ...the sloppy tm_to_time_t() code does not handle conversions past 2100 due to the leap year skip there. There's more discussion in: https://lore.kernel.org/git/20240604093345.GA1279521@xxxxxxxxxxxxxxxxxxxxxxx/ That message mentions patches to handle negative timestamps completely. You can see them here: https://github.com/peff/git/jk/time-negative-wip It works fine on Linux, but IIRC I got stuck on the system time-handling functions of Windows being unhappy. Probably solvable by implementing more custom code. If you're interested in trying to push it over the finish line, I'd be happy to discuss it. Although... > I’d also expect that correctly formatted time stamps containing valid > date & time information should be processed correctly. (at least for > dates after Friday 15 October 1582 (as the day before was Thursday 4 > October 1582) I'm not sure how my implementation would handle this. The tm_to_time_t() fallback doesn't know anything about historical calendar shifts, and going in the reverse direction would depend on your system gmtime(). So probably: - if you feed a correct epoch timestamp for October 4th (e.g., "git commit --date=@-") you may or may not get the right result. Certainly on Windows if we have to use fallback code you wouldn't. But even GNU date doesn't seem to handle this: $ date --date=@-12219361438 Thu Oct 14 00:00:00 LMT 1582 - we'd always use custom code for going the other way. So: git commit --date=1582-10-04 would give you an epoch 11 days before the 15th, not 1 day. Even still, IMHO handling negative timestamps at all would be a huge improvement over the status quo. And we should be correct down to the second for "recent" stuff (like say, code written in the 1960's). -Peff
