From fe1b11bf5a752743167018f77e2826304ba0aa0e Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Fri, 17 Sep 2021 13:40:07 +0900 Subject: search: fix rt: w/ approxidate when TZ != UTC While git respects a user's local timezone and returns seconds-since-the-Epoch, we were unnecessarily and incorrectly calling gmtime+strftime on its result. So ignore calling gmtime+strftime when the strftime format is "%s", just feed the output time from git directly to Xapian. This is mainly for lei, which will likely run in a variety of timezones. While we're at it, add a recommendation to use TZ=UTC in public-inbox-httpd, in case there are (misguided :P) sysadmins who set a non-UTC TZ. --- lib/PublicInbox/Search.pm | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) (limited to 'lib') diff --git a/lib/PublicInbox/Search.pm b/lib/PublicInbox/Search.pm index e80a5944..af0a35d9 100644 --- a/lib/PublicInbox/Search.pm +++ b/lib/PublicInbox/Search.pm @@ -332,7 +332,7 @@ sub date_parse_prepare { push @$to_parse, $x; $x = "\0%s$#$to_parse\0"; } - $r[1] //= "\0%s+\0"; + $r[1] //= "\0%s+\0"; # add 1 day } "$pfx:".join('..', @r).$end; } @@ -342,9 +342,12 @@ sub date_parse_finalize { # git-rev-parse can handle any number of args up to system # limits (around (4096*32) bytes on Linux). my @r = $git->date_parse(@$to_parse); - my $i; - $_[2] =~ s/\0(%[%YmdHMSs]+)([0-9\+]+)\0/strftime($1, - gmtime($2 eq '+' ? ($r[$i]+86400) : $r[$i=$2+0]))/sge; + # n.b. git respects TZ, times stored in SQLite/Xapian are always UTC, + # and gmtime doesn't seem to do the right thing when TZ!=UTC + my ($i, $t); + $_[2] =~ s/\0(%[%YmdHMSs]+)([0-9\+]+)\0/ + $t = $2 eq '+' ? ($r[$i]+86400) : $r[$i=$2+0]; + $1 eq '%s' ? $t : strftime($1, gmtime($t))/sge; } # n.b. argv never has NUL, though we'll need to filter it out -- cgit v1.2.3-24-ge0c7