Hi Peff, On Tue, 12 Jul 2016, Jeff King wrote: > On Tue, Jul 12, 2016 at 01:25:20PM +0200, Johannes Schindelin wrote: > > > [PATCH] Work around test failures due to timestamps being unsigned long > > > > Git's source code refers to timestamps as unsigned longs. On 32-bit > > platforms, as well as on Windows, unsigned long is not large enough to > > capture dates that are "absurdly far in the future". > > > > While we will fix this issue properly by replacing unsigned long -> > > time_t, on the maint track we want to be a bit more conservative and > > just skip those tests. > > > > Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> > > --- > > This looks like a reasonable interim fix for both Windows and for the > general maint track. If we reliably produce "2038" for the 999... value > then that's simpler than adding in magic to ask about sizeof(ulong). I > also wondered if we should test forthe _correct_ value, but that would > defeat the point of the test (999... is also far in the future). This was just a quick fix, intended to allow me to release Git for Windows v2.9.1 in a timely manner (which is now delayed for other reasons). I think I can do even better than to inspect the source code whether it reliably clamps the dates to PI hours on January 19th, 2038: We already have a t/helper/test-date and we can easily teach it one new trick. > One minor comment: > > > diff --git a/t/t0006-date.sh b/t/t0006-date.sh > > index 04ce535..d185640 100755 > > --- a/t/t0006-date.sh > > +++ b/t/t0006-date.sh > > @@ -48,10 +48,17 @@ check_show default "$TIME" 'Wed Jun 15 16:13:20 2016 +0200' > > check_show raw "$TIME" '1466000000 +0200' > > check_show iso-local "$TIME" '2016-06-15 14:13:20 +0000' > > > > -# arbitrary time absurdly far in the future > > -FUTURE="5758122296 -0400" > > -check_show iso "$FUTURE" "2152-06-19 18:24:56 -0400" > > -check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +0000" > > +case "$(test-date show:iso 9999999999)" in > > +*2038*) > > + # on this platform, unsigned long is 32-bit, i.e. not large enough > > + ;; > > +*) > > + # arbitrary time absurdly far in the future > > + FUTURE="5758122296 -0400" > > + check_show iso "$FUTURE" "2152-06-19 18:24:56 -0400" > > + check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +0000" > > + ;; > > +esac > > It would be nice to wrap this in a prereq, like: > > test_lazy_prereq 64BIT_TIME ' > case "$(test-date show:short 9999999999)" in > *2038*) > false > ;; > *) > true > ;; > esac > ' > > ... > check_show 64BIT_TIME iso "$FUTURE" "2152-06-19 18:24:56 -0400" > check_show 64BIT_TIME iso-local "$FUTURE" "2152-06-19 22:24:56 +0000" > > The main advantage is that it will number the tests consistently, and > give us a "skipped" message (which can remind us to drop the prereq > later when everything goes 64-bit). > > But it also will do the right thing with test-date's output with respect > to "-v" (not that we expect it to produce any output). > > You'll need to adjust check_show as I did in my earlier patch. Makes sense! Thanks, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html