Re: [PATCH] Call timegm and timelocal with 4-digit year

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Feb 23 2018, Bernhard M. Wiedemann jotted:

> amazingly timegm(gmtime(0)) is only 0 before 2020
> because perl's timegm deviates from GNU timegm(3) in how it handles years.
>
> man Time::Local says
>
>  Whenever possible, use an absolute four digit year instead.
>
> with a detailed explanation about ambiguity of 2-digit years above that.
>
> Even though this ambiguity is error-prone with >50% of users getting it
> wrong, it has been like this for 20+ years, so we just use 4-digit years
> everywhere to be on the safe side.
>
> We add some extra logic to cvsimport because it allows 2-digit year
> input and interpreting an 18 as 1918 can be avoided easily and safely.
>
> Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
> ---
>  contrib/examples/git-svnimport.perl | 2 +-
>  git-cvsimport.perl                  | 4 +++-
>  perl/Git.pm                         | 4 +++-
>  perl/Git/SVN.pm                     | 2 +-
>  4 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/contrib/examples/git-svnimport.perl b/contrib/examples/git-svnimport.perl
> index c414f0d9c..75a43e23b 100755
> --- a/contrib/examples/git-svnimport.perl
> +++ b/contrib/examples/git-svnimport.perl
> @@ -238,7 +238,7 @@ sub pdate($) {
>  	my($d) = @_;
>  	$d =~ m#(\d\d\d\d)-(\d\d)-(\d\d)T(\d\d):(\d\d):(\d\d)#
>  		or die "Unparseable date: $d\n";
> -	my $y=$1; $y-=1900 if $y>1900;
> +	my $y=$1; $y+=1900 if $y<1000;
>  	return timegm($6||0,$5,$4,$3,$2-1,$y);

I wonder if this whole thing was just cargo-culted to begin with. We
need to match (\d\d\d\d) here, so did SVN's format ever have years like
"0098" (just "98" wouldn't match), so I suspect the whole munging could
be dropped, but this change seems harmless. Just something that jumped
out at me reviewing this.

> diff --git a/git-cvsimport.perl b/git-cvsimport.perl
> index 2d8df8317..b31613cb8 100755
> --- a/git-cvsimport.perl
> +++ b/git-cvsimport.perl
> @@ -601,7 +601,9 @@ sub pdate($) {
>  	my ($d) = @_;
>  	m#(\d{2,4})/(\d\d)/(\d\d)\s(\d\d):(\d\d)(?::(\d\d))?#
>  		or die "Unparseable date: $d\n";
> -	my $y=$1; $y-=1900 if $y>1900;
> +	my $y=$1;
> +	$y+=100 if $y<70;
> +	$y+=1900 if $y<1000;
>  	return timegm($6||0,$5,$4,$3,$2-1,$y);
>  }

My Time::Local 1.2300 on perl 5.024001 currently interprets "69" here as
1969, but after this it'll be 2069.

Now I doubt anyone's going to be importing CVS history of projects a
little over 20 years before CVS was created in 1990 (although I suppose
old imports...), but just wanted to note it since it seems odd for code
that's auto-interpreting double digit years for the purposes of
importing existing data to end up in an edge case where it returns dates
more than 50 years in the future.

> diff --git a/perl/Git.pm b/perl/Git.pm
> index ffa09ace9..df62518c7 100644
> --- a/perl/Git.pm
> +++ b/perl/Git.pm
> @@ -534,7 +534,9 @@ If TIME is not supplied, the current local time is used.
>  sub get_tz_offset {
>  	# some systems don't handle or mishandle %z, so be creative.
>  	my $t = shift || time;
> -	my $gm = timegm(localtime($t));
> +	my @t = localtime($t);
> +	$t[5] += 1900;
> +	my $gm = timegm(@t);
>

Nice. Just using the 4-digit date is always more correct and won't ever
be buggy.

>  	my $sign = qw( + + - )[ $gm <=> $t ];
>  	return sprintf("%s%02d%02d", $sign, (gmtime(abs($t - $gm)))[2,1]);
>  }
> diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
> index bc4eed3d7..991a5885e 100644
> --- a/perl/Git/SVN.pm
> +++ b/perl/Git/SVN.pm
> @@ -1405,7 +1405,7 @@ sub parse_svn_date {
>  		$ENV{TZ} = 'UTC';
>
>  		my $epoch_in_UTC =
> -		    Time::Local::timelocal($S, $M, $H, $d, $m - 1, $Y - 1900);
> +		    Time::Local::timelocal($S, $M, $H, $d, $m - 1, $Y);

Ditto. Nicely caught.

>
>  		# Determine our local timezone (including DST) at the
>  		# time of $epoch_in_UTC.  $Git::SVN::Log::TZ stored the

Anyway, this all looks good to me as-is. That CVS edge case is obscure
and not worth focusing on, and the SVN one could be fixed up in another
commit if anyone cared.

I just spent a bit more time than I should have wondering what this
timegm() edge case was about and whether it might impact other
(unrelated to git) code I had.