Re: Date and time processing issue

[Jeff King <peff@peff.net>]

On Fri, Aug 02, 2024 at 11:46:30AM +0200, the.tester@mac.com 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@coredump.intra.peff.net/

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