[PATCH] t9604: Fix test for musl libc and new Debian

[PATCH] t9604: Fix test for musl libc and new Debian

[Đoàn Trần Công Danh]

CST6CDT and the like are POSIX timezone, with no rule for transition.
And POSIX doesn't enforce how to interpret the rule if it's omited.
Some libc resorted back to IANA (formerly Olson) db rules for those
timezones.  Other libc (e.g. musl) interpret that as no transition at
all [1].

In addition, distributions (notoriously Debian-derived, which uses IANA
db for CST6CDT and the like) started to split "legacy" timezones
like CST6CDT, EST5EDT into `tzdata-legacy', which will not be installed
by default [2].

In those cases, t9604 will run into failure.

Let's switch to POSIX timezone with rules to change timezone.

1: http://mm.icann.org/pipermail/tz/2024-March/058751.html
2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043250

Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
---
* Note that since our tests are pre-2007, I use the old rules in the timezone.
* We can also use IANA notations, which I believe is better, but that mean we
  will depends on IANA db
 t/t9604-cvsimport-timestamps.sh | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604-cvsimport-timestamps.sh
index 2ff4aa932df44..07560d4779872 100755
--- a/t/t9604-cvsimport-timestamps.sh
+++ b/t/t9604-cvsimport-timestamps.sh
@@ -5,9 +5,10 @@ test_description='git cvsimport timestamps'
 
 setup_cvs_test_repository t9604
 
-test_expect_success PERL 'check timestamps are UTC (TZ=CST6CDT)' '
+test_expect_success PERL 'check timestamps are UTC (TZ=America/Chicago)' '
 
-	TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
+	TZ=CST6CDT,M4.1.0,M10.5.0 \
+	git cvsimport -p"-x" -C module-1 module &&
 	git cvsimport -p"-x" -C module-1 module &&
 	(
 		cd module-1 &&
@@ -38,9 +39,9 @@ test_expect_success PERL 'check timestamps with author-specific timezones' '
 
 	cat >cvs-authors <<-EOF &&
 	user1=User One <user1@domain.org>
-	user2=User Two <user2@domain.org> CST6CDT
-	user3=User Three <user3@domain.org> EST5EDT
-	user4=User Four <user4@domain.org> MST7MDT
+	user2=User Two <user2@domain.org> CST6CDT,M4.1.0,M10.5.0
+	user3=User Three <user3@domain.org> EST5EDT,M4.1.0,M10.5.0
+	user4=User Four <user4@domain.org> MST7MDT,M4.1.0,M10.5.0
 	EOF
 	git cvsimport -p"-x" -A cvs-authors -C module-2 module &&
 	(
-- 
2.44.0.rc0.258.g7320e9588666f

Re: [PATCH] t9604: Fix test for musl libc and new Debian

[Junio C Hamano]

Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:

> * Note that since our tests are pre-2007, I use the old rules in the timezone.
> * We can also use IANA notations, which I believe is better, but that mean we
>   will depends on IANA db

I know of the ",start[/time],end[/time]" thing tucked after the
zonename, but haven't seen it used in real life.  How confident are
you that it is widely supported?  I do understand that you saw these
current tests do fail on some platforms, but we'd want to make sure
that we are not breaking other platforms by switching.

> -test_expect_success PERL 'check timestamps are UTC (TZ=CST6CDT)' '
> +test_expect_success PERL 'check timestamps are UTC (TZ=America/Chicago)' '
>  
> -	TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
> +	TZ=CST6CDT,M4.1.0,M10.5.0 \
> +	git cvsimport -p"-x" -C module-1 module &&
>  	git cvsimport -p"-x" -C module-1 module &&
>  	(
>  		cd module-1 &&

A few things curious about this hunk.

 - The test title says America/Chicago but that timezone is never
   used.  Would it make sense to actually use it for tests?

 - If not, shouldn't we at least use the actual timezone we use for
   tests?

 - Do we really want to run cvsimport twice?

> @@ -38,9 +39,9 @@ test_expect_success PERL 'check timestamps with author-specific timezones' '
>  
>  	cat >cvs-authors <<-EOF &&
>  	user1=User One <user1@domain.org>
> -	user2=User Two <user2@domain.org> CST6CDT
> -	user3=User Three <user3@domain.org> EST5EDT
> -	user4=User Four <user4@domain.org> MST7MDT
> +	user2=User Two <user2@domain.org> CST6CDT,M4.1.0,M10.5.0
> +	user3=User Three <user3@domain.org> EST5EDT,M4.1.0,M10.5.0
> +	user4=User Four <user4@domain.org> MST7MDT,M4.1.0,M10.5.0
>  	EOF
>  	git cvsimport -p"-x" -A cvs-authors -C module-2 module &&
>  	(

Re: [PATCH] t9604: Fix test for musl libc and new Debian

[Jeff King]

On Sat, Apr 06, 2024 at 10:29:10AM +0700, Đoàn Trần Công Danh wrote:

> CST6CDT and the like are POSIX timezone, with no rule for transition.
> And POSIX doesn't enforce how to interpret the rule if it's omited.
> Some libc resorted back to IANA (formerly Olson) db rules for those
> timezones.  Other libc (e.g. musl) interpret that as no transition at
> all [1].
> 
> In addition, distributions (notoriously Debian-derived, which uses IANA
> db for CST6CDT and the like) started to split "legacy" timezones
> like CST6CDT, EST5EDT into `tzdata-legacy', which will not be installed
> by default [2].
> 
> In those cases, t9604 will run into failure.
> 
> Let's switch to POSIX timezone with rules to change timezone.

This made me wonder if we are losing EST5, etc. We use that in t0006,
for example. But I guess not, since I do not have tzdata-legacy
installed (I am on Debian unstable) and haven't run into issues (I
didn't notice the cvsimport one because I lack other prereqs to run
those tests).

-Peff

Re: [PATCH] t9604: Fix test for musl libc and new Debian

[Đoàn Trần Công Danh]

On 2024-04-06 05:11:30-0700, Junio C Hamano <gitster@pobox.com> wrote:
> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:
> 
> > * Note that since our tests are pre-2007, I use the old rules in the timezone.
> > * We can also use IANA notations, which I believe is better, but that mean we
> >   will depends on IANA db
> 
> I know of the ",start[/time],end[/time]" thing tucked after the
> zonename, but haven't seen it used in real life.

The notation can be found in OpenWRT because Olson db takes spaces
(and update).

> How confident are you that it is widely supported?

To be honest, I'm not sure.  I know that Linux musl, glibc, uClibc,
all BSDs, and Darwin supports that.
I also think System V SVR4 supports that notation [1], and
its successors (HP-UX [2], Solaris [3], UnixWare [1], AIX [4]) seems to supports it.

1: https://mm.icann.org/pipermail/tz/1994-May/009304.html
2: HP-UX is conformed to UNIX-03, its support should be there
   https://www.opengroup.org/openbrand/register/xy.htm
3: For Solaris, at least Fujitsu SPARC supports POSIX timezone
   https://jp.fujitsu.com/platform/server/sparc/manual/en/c120-e679/3.6.5.html
4: https://www.ibm.com/support/pages/managing-time-zone-variable-posix 

Those companies seem to claim their product supports POSIX timezone:
- SCO Unix: http://osr600doc.sco.com/en/man/html.M/environ.M.html
- QNX: https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.user_guide/topic/environment_TimeZone.html

From those webpages, I think those OS also support POSIX timezone
notation:
- OSF/1 and Tru64 https://www.unix.com/man-page/osf1/3/tzname/
- IRIX: https://nixdoc.net/man-pages/IRIX/man5/environ.5.html
- Interix: https://ftp.zx.net.nz/pub/archive/ftp.microsoft.com/MISC/KB/en-us/246/420.HTM
- Minix: https://www.unix.com/man-page/minix/5/tz/

I don't know about NonStop, z/OS and OS/390, but I think our list has
people who actively working on them. May we ask them to confirm?

> I do understand that you saw these
> current tests do fail on some platforms, but we'd want to make sure
> that we are not breaking other platforms by switching.
> 
> > -test_expect_success PERL 'check timestamps are UTC (TZ=CST6CDT)' '
> > +test_expect_success PERL 'check timestamps are UTC (TZ=America/Chicago)' '
> >  
> > -	TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
> > +	TZ=CST6CDT,M4.1.0,M10.5.0 \
> > +	git cvsimport -p"-x" -C module-1 module &&
> >  	git cvsimport -p"-x" -C module-1 module &&
> >  	(
> >  		cd module-1 &&
> 
> A few things curious about this hunk.
> 
>  - The test title says America/Chicago but that timezone is never
>    used.  Would it make sense to actually use it for tests?
> 
>  - If not, shouldn't we at least use the actual timezone we use for
>    tests?
> 
>  - Do we really want to run cvsimport twice?

Well, when I tried to make this change, I first started with Olson
notation. Then I dig into the mail archive, and I see that we don't
want to depends on IANA db [5].  Then I switch to POSIX notation but
I forgot to update that.  I think a PREREQ would work better?

5: https://lore.kernel.org/git/7v4nlvulc2.fsf@alter.siamese.dyndns.org/

> > @@ -38,9 +39,9 @@ test_expect_success PERL 'check timestamps with author-specific timezones' '
> >  
> >  	cat >cvs-authors <<-EOF &&
> >  	user1=User One <user1@domain.org>
> > -	user2=User Two <user2@domain.org> CST6CDT
> > -	user3=User Three <user3@domain.org> EST5EDT
> > -	user4=User Four <user4@domain.org> MST7MDT
> > +	user2=User Two <user2@domain.org> CST6CDT,M4.1.0,M10.5.0
> > +	user3=User Three <user3@domain.org> EST5EDT,M4.1.0,M10.5.0
> > +	user4=User Four <user4@domain.org> MST7MDT,M4.1.0,M10.5.0
> >  	EOF
> >  	git cvsimport -p"-x" -A cvs-authors -C module-2 module &&
> >  	(

-- 
Danh

Re: [PATCH] t9604: Fix test for musl libc and new Debian

[Đoàn Trần Công Danh]

On 2024-04-06 21:33:12-0400, Jeff King <peff@peff.net> wrote:
> On Sat, Apr 06, 2024 at 10:29:10AM +0700, Đoàn Trần Công Danh wrote:
> 
> > CST6CDT and the like are POSIX timezone, with no rule for transition.
> > And POSIX doesn't enforce how to interpret the rule if it's omited.
> > Some libc resorted back to IANA (formerly Olson) db rules for those
> > timezones.  Other libc (e.g. musl) interpret that as no transition at
> > all [1].
> > 
> > In addition, distributions (notoriously Debian-derived, which uses IANA
> > db for CST6CDT and the like) started to split "legacy" timezones
> > like CST6CDT, EST5EDT into `tzdata-legacy', which will not be installed
> > by default [2].
> > 
> > In those cases, t9604 will run into failure.
> > 
> > Let's switch to POSIX timezone with rules to change timezone.
> 
> This made me wonder if we are losing EST5, etc. We use that in t0006,
> for example. But I guess not, since I do not have tzdata-legacy
> installed (I am on Debian unstable) and haven't run into issues (I
> didn't notice the cvsimport one because I lack other prereqs to run
> those tests).

Nah, EST5 is a conformance POSIX timezone.  It read:

    The timezone name is EST, offset is 5hours behinds Universal timezone.

You can check by trying today (or on anyday with DST on):

	TZ=EST5 date
	TZ=EST5EDT date
	TZ=America/New_York date

- The first one will always interpret 5 hours behinds UTC.
- The second one is implementation defined behavior, on glibc system,
  it will depends on the existence of /usr/share/zoneinfo/EST5EDT
- The third one will interpret today time as 4 hours behinds UTC.

glibc normally check if a timezone exist in /usr/share/zoneinfo first,
if not, it will interpret by POSIX rule.

-- 
Danh

Re: [PATCH] t9604: Fix test for musl libc and new Debian

[Đoàn Trần Công Danh]

On 2024-04-07 08:45:38+0700, Đoàn Trần Công Danh <congdanhqx@gmail.com> wrote:
> On 2024-04-06 21:33:12-0400, Jeff King <peff@peff.net> wrote:
> > On Sat, Apr 06, 2024 at 10:29:10AM +0700, Đoàn Trần Công Danh wrote:
> > 
> > > CST6CDT and the like are POSIX timezone, with no rule for transition.
> > > And POSIX doesn't enforce how to interpret the rule if it's omited.
> > > Some libc resorted back to IANA (formerly Olson) db rules for those
> > > timezones.  Other libc (e.g. musl) interpret that as no transition at
> > > all [1].
> > > 
> > > In addition, distributions (notoriously Debian-derived, which uses IANA
> > > db for CST6CDT and the like) started to split "legacy" timezones
> > > like CST6CDT, EST5EDT into `tzdata-legacy', which will not be installed
> > > by default [2].
> > > 
> > > In those cases, t9604 will run into failure.
> > > 
> > > Let's switch to POSIX timezone with rules to change timezone.
> > 
> > This made me wonder if we are losing EST5, etc. We use that in t0006,
> > for example. But I guess not, since I do not have tzdata-legacy
> > installed (I am on Debian unstable) and haven't run into issues (I
> > didn't notice the cvsimport one because I lack other prereqs to run
> > those tests).
> 
> Nah, EST5 is a conformance POSIX timezone.  It read:
> 
>     The timezone name is EST, offset is 5hours behinds Universal timezone.

Correction: it reads
      The timezone name is EST, offset is 5hours behinds Universal timezone,
      all year round.

Since POSIX says that:

	if dst is missing, then the alternative time does not apply in
	this locale.

> 
> You can check by trying today (or on anyday with DST on):
> 
> 	TZ=EST5 date
> 	TZ=EST5EDT date
> 	TZ=America/New_York date
> 
> - The first one will always interpret 5 hours behinds UTC.
> - The second one is implementation defined behavior, on glibc system,
>   it will depends on the existence of /usr/share/zoneinfo/EST5EDT
> - The third one will interpret today time as 4 hours behinds UTC.
> 
> glibc normally check if a timezone exist in /usr/share/zoneinfo first,
> if not, it will interpret by POSIX rule.
> 
> -- 
> Danh

-- 
Danh

Re: [PATCH] t9604: Fix test for musl libc and new Debian

[Junio C Hamano]

Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:

> Well, when I tried to make this change, I first started with Olson
> notation. Then I dig into the mail archive, and I see that we don't
> want to depends on IANA db [5].  Then I switch to POSIX notation but
> I forgot to update that.  I think a PREREQ would work better?
>
> 5: https://lore.kernel.org/git/7v4nlvulc2.fsf@alter.siamese.dyndns.org/

Interesting thought to use PREREQ here.  As long as it will avoid
tempting us into testing the feature only where we know that the
feature would work, I am OK with that direction ;-)

Thanks.

[PATCH v2] t9604: Fix test for musl libc and new Debian

[Đoàn Trần Công Danh]

CST6CDT and the like are POSIX timezone, with no rule for transition.
And POSIX doesn't enforce how to interpret the rule if it's omited.
Some libc (e.g. glibc) resorted back to IANA (formerly Olson) db rules
for those timezones.  Some libc (e.g. FreeBSD) uses a fixed rule.
Other libc (e.g. musl) interpret that as no transition at all [1].

In addition, distributions (notoriously Debian-derived, which uses IANA
db for CST6CDT and the like) started to split "legacy" timezones
like CST6CDT, EST5EDT into `tzdata-legacy', which will not be installed
by default [2].

In those cases, t9604 will run into failure.

Let's switch to POSIX timezone with rules to change timezone.

1: http://mm.icann.org/pipermail/tz/2024-March/058751.html
2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043250

Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
---
Range-diff against v1:
1:  23a4298eababe ! 1:  9494adb39120c t9604: Fix test for musl libc and new Debian
    @@ Commit message
     
         CST6CDT and the like are POSIX timezone, with no rule for transition.
         And POSIX doesn't enforce how to interpret the rule if it's omited.
    -    Some libc resorted back to IANA (formerly Olson) db rules for those
    -    timezones.  Other libc (e.g. musl) interpret that as no transition at
    -    all [1].
    +    Some libc (e.g. glibc) resorted back to IANA (formerly Olson) db rules
    +    for those timezones.  Some libc (e.g. FreeBSD) uses a fixed rule.
    +    Other libc (e.g. musl) interpret that as no transition at all [1].
     
         In addition, distributions (notoriously Debian-derived, which uses IANA
         db for CST6CDT and the like) started to split "legacy" timezones
    @@ Commit message
         Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
     
      ## t/t9604-cvsimport-timestamps.sh ##
    -@@ t/t9604-cvsimport-timestamps.sh: test_description='git cvsimport timestamps'
    +@@
    + test_description='git cvsimport timestamps'
    + . ./lib-cvs.sh
      
    ++test_lazy_prereq POSIX_TIMEZONE '
    ++	local tz=XST-1XDT,M3.5.0,M11.1.0
    ++	echo "1711846799 -> 2024-03-31 01:59:59 +0100" >expected &&
    ++	TZ="$tz" test-tool date show:iso-local 1711846799 >actual &&
    ++	test_cmp expected actual &&
    ++	echo "1711846800 -> 2024-03-31 03:00:00 +0200" >expected &&
    ++	TZ="$tz" test-tool date show:iso-local 1711846800 >actual &&
    ++	test_cmp expected actual &&
    ++	echo "1730591999 -> 2024-11-03 01:59:59 +0200" >expected &&
    ++	TZ="$tz" test-tool date show:iso-local 1730591999 >actual &&
    ++	test_cmp expected actual &&
    ++	echo "1730592000 -> 2024-11-03 01:00:00 +0100" >expected &&
    ++	TZ="$tz" test-tool date show:iso-local 1730592000 >actual &&
    ++	test_cmp expected actual
    ++'
    ++
      setup_cvs_test_repository t9604
      
     -test_expect_success PERL 'check timestamps are UTC (TZ=CST6CDT)' '
    -+test_expect_success PERL 'check timestamps are UTC (TZ=America/Chicago)' '
    ++test_expect_success PERL,POSIX_TIMEZONE 'check timestamps are UTC' '
      
     -	TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
     +	TZ=CST6CDT,M4.1.0,M10.5.0 \
    @@ t/t9604-cvsimport-timestamps.sh: test_description='git cvsimport timestamps'
      	git cvsimport -p"-x" -C module-1 module &&
      	(
      		cd module-1 &&
    -@@ t/t9604-cvsimport-timestamps.sh: test_expect_success PERL 'check timestamps with author-specific timezones' '
    +@@ t/t9604-cvsimport-timestamps.sh: test_expect_success PERL 'check timestamps are UTC (TZ=CST6CDT)' '
    + 	test_cmp expect-1 actual-1
    + '
    + 
    +-test_expect_success PERL 'check timestamps with author-specific timezones' '
    ++test_expect_success PERL,POSIX_TIMEZONE 'check timestamps with author-specific timezones' '
      
      	cat >cvs-authors <<-EOF &&
      	user1=User One <user1@domain.org>

 t/t9604-cvsimport-timestamps.sh | 29 +++++++++++++++++++++++------
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604-cvsimport-timestamps.sh
index 2ff4aa932df44..2d03259729b5f 100755
--- a/t/t9604-cvsimport-timestamps.sh
+++ b/t/t9604-cvsimport-timestamps.sh
@@ -3,11 +3,28 @@
 test_description='git cvsimport timestamps'
 . ./lib-cvs.sh
 
+test_lazy_prereq POSIX_TIMEZONE '
+	local tz=XST-1XDT,M3.5.0,M11.1.0
+	echo "1711846799 -> 2024-03-31 01:59:59 +0100" >expected &&
+	TZ="$tz" test-tool date show:iso-local 1711846799 >actual &&
+	test_cmp expected actual &&
+	echo "1711846800 -> 2024-03-31 03:00:00 +0200" >expected &&
+	TZ="$tz" test-tool date show:iso-local 1711846800 >actual &&
+	test_cmp expected actual &&
+	echo "1730591999 -> 2024-11-03 01:59:59 +0200" >expected &&
+	TZ="$tz" test-tool date show:iso-local 1730591999 >actual &&
+	test_cmp expected actual &&
+	echo "1730592000 -> 2024-11-03 01:00:00 +0100" >expected &&
+	TZ="$tz" test-tool date show:iso-local 1730592000 >actual &&
+	test_cmp expected actual
+'
+
 setup_cvs_test_repository t9604
 
-test_expect_success PERL 'check timestamps are UTC (TZ=CST6CDT)' '
+test_expect_success PERL,POSIX_TIMEZONE 'check timestamps are UTC' '
 
-	TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
+	TZ=CST6CDT,M4.1.0,M10.5.0 \
+	git cvsimport -p"-x" -C module-1 module &&
 	git cvsimport -p"-x" -C module-1 module &&
 	(
 		cd module-1 &&
@@ -34,13 +51,13 @@ test_expect_success PERL 'check timestamps are UTC (TZ=CST6CDT)' '
 	test_cmp expect-1 actual-1
 '
 
-test_expect_success PERL 'check timestamps with author-specific timezones' '
+test_expect_success PERL,POSIX_TIMEZONE 'check timestamps with author-specific timezones' '
 
 	cat >cvs-authors <<-EOF &&
 	user1=User One <user1@domain.org>
-	user2=User Two <user2@domain.org> CST6CDT
-	user3=User Three <user3@domain.org> EST5EDT
-	user4=User Four <user4@domain.org> MST7MDT
+	user2=User Two <user2@domain.org> CST6CDT,M4.1.0,M10.5.0
+	user3=User Three <user3@domain.org> EST5EDT,M4.1.0,M10.5.0
+	user4=User Four <user4@domain.org> MST7MDT,M4.1.0,M10.5.0
 	EOF
 	git cvsimport -p"-x" -A cvs-authors -C module-2 module &&
 	(
-- 
2.44.0.rc0.258.g7320e9588666f

Re: [PATCH v2] t9604: Fix test for musl libc and new Debian

[Eric Sunshine]

On Tue, Apr 9, 2024 at 11:28 PM Đoàn Trần Công Danh
<congdanhqx@gmail.com> wrote:
> CST6CDT and the like are POSIX timezone, with no rule for transition.
> And POSIX doesn't enforce how to interpret the rule if it's omited.
> Some libc (e.g. glibc) resorted back to IANA (formerly Olson) db rules
> for those timezones.  Some libc (e.g. FreeBSD) uses a fixed rule.
> Other libc (e.g. musl) interpret that as no transition at all [1].

s/omited/omitted/

> In addition, distributions (notoriously Debian-derived, which uses IANA
> db for CST6CDT and the like) started to split "legacy" timezones
> like CST6CDT, EST5EDT into `tzdata-legacy', which will not be installed
> by default [2].
>
> In those cases, t9604 will run into failure.
>
> Let's switch to POSIX timezone with rules to change timezone.
>
> 1: http://mm.icann.org/pipermail/tz/2024-March/058751.html
> 2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043250
>
> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>

Re: [PATCH v2] t9604: Fix test for musl libc and new Debian

[Đoàn Trần Công Danh]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

On 2024-04-10 10:28:12+0700, Đoàn Trần Công Danh <congdanhqx@gmail.com> wrote:
> -test_expect_success PERL 'check timestamps with author-specific timezones' '
> +test_expect_success PERL,POSIX_TIMEZONE 'check timestamps with author-specific timezones' '
>  
>  	cat >cvs-authors <<-EOF &&
>  	user1=User One <user1@domain.org>
> -	user2=User Two <user2@domain.org> CST6CDT
> -	user3=User Three <user3@domain.org> EST5EDT
> -	user4=User Four <user4@domain.org> MST7MDT
> +	user2=User Two <user2@domain.org> CST6CDT,M4.1.0,M10.5.0
> +	user3=User Three <user3@domain.org> EST5EDT,M4.1.0,M10.5.0
> +	user4=User Four <user4@domain.org> MST7MDT,M4.1.0,M10.5.0

Not sure if it's a good idea to change those CST6CDT, EST5EDT MST7MDT
to some non-sense likes: XST6XDT, YST5YDT, ZST7ZDT, though.
Since those characters are for decoration purpose

>  	EOF
>  	git cvsimport -p"-x" -A cvs-authors -C module-2 module &&
>  	(
> -- 
> 2.44.0.rc0.258.g7320e9588666f
> 

-- 
Danh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2] t9604: Fix test for musl libc and new Debian

[Eric Sunshine]

On Tue, Apr 9, 2024 at 11:28 PM Đoàn Trần Công Danh
<congdanhqx@gmail.com> wrote:
> CST6CDT and the like are POSIX timezone, with no rule for transition.
> And POSIX doesn't enforce how to interpret the rule if it's omited.
> Some libc (e.g. glibc) resorted back to IANA (formerly Olson) db rules
> for those timezones.  Some libc (e.g. FreeBSD) uses a fixed rule.
> Other libc (e.g. musl) interpret that as no transition at all [1].
>
> In addition, distributions (notoriously Debian-derived, which uses IANA
> db for CST6CDT and the like) started to split "legacy" timezones
> like CST6CDT, EST5EDT into `tzdata-legacy', which will not be installed
> by default [2].
>
> In those cases, t9604 will run into failure.
>
> Let's switch to POSIX timezone with rules to change timezone.
>
> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
> ---
> diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604-cvsimport-timestamps.sh
> @@ -3,11 +3,28 @@
> +test_expect_success PERL,POSIX_TIMEZONE 'check timestamps are UTC' '
>
> -       TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
> +       TZ=CST6CDT,M4.1.0,M10.5.0 \
> +       git cvsimport -p"-x" -C module-1 module &&
>         git cvsimport -p"-x" -C module-1 module &&

Is this duplicated `git cvsimport` invocation intentional?

Re: [PATCH v2] t9604: Fix test for musl libc and new Debian

[Đoàn Trần Công Danh]

On 2024-04-09 23:37:16-0400, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Tue, Apr 9, 2024 at 11:28 PM Đoàn Trần Công Danh
> <congdanhqx@gmail.com> wrote:
> > CST6CDT and the like are POSIX timezone, with no rule for transition.
> > And POSIX doesn't enforce how to interpret the rule if it's omited.
> > Some libc (e.g. glibc) resorted back to IANA (formerly Olson) db rules
> > for those timezones.  Some libc (e.g. FreeBSD) uses a fixed rule.
> > Other libc (e.g. musl) interpret that as no transition at all [1].
> >
> > In addition, distributions (notoriously Debian-derived, which uses IANA
> > db for CST6CDT and the like) started to split "legacy" timezones
> > like CST6CDT, EST5EDT into `tzdata-legacy', which will not be installed
> > by default [2].
> >
> > In those cases, t9604 will run into failure.
> >
> > Let's switch to POSIX timezone with rules to change timezone.
> >
> > Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com>
> > ---
> > diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604-cvsimport-timestamps.sh
> > @@ -3,11 +3,28 @@
> > +test_expect_success PERL,POSIX_TIMEZONE 'check timestamps are UTC' '
> >
> > -       TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
> > +       TZ=CST6CDT,M4.1.0,M10.5.0 \
> > +       git cvsimport -p"-x" -C module-1 module &&
> >         git cvsimport -p"-x" -C module-1 module &&
> 
> Is this duplicated `git cvsimport` invocation intentional?

I have no idea whether that was intentional, it's there from the very
begining.  Apply this diff on top of my change, and tests still pass.
----- 8< ------

 t/t9604-cvsimport-timestamps.sh | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604-cvsimport-timestamps.sh
index 2d03259729b5f..c51a9fa8b6ca6 100755
--- a/t/t9604-cvsimport-timestamps.sh
+++ b/t/t9604-cvsimport-timestamps.sh
@@ -25,11 +25,7 @@ test_expect_success PERL,POSIX_TIMEZONE 'check timestamps are UTC' '
 
 	TZ=CST6CDT,M4.1.0,M10.5.0 \
 	git cvsimport -p"-x" -C module-1 module &&
-	git cvsimport -p"-x" -C module-1 module &&
-	(
-		cd module-1 &&
-		git log --format="%s %ai"
-	) >actual-1 &&
+	git -C module-1 log --format="%s %ai" >actual-1 &&
 	cat >expect-1 <<-EOF &&
 	Rev 16 2006-10-29 07:00:01 +0000
 	Rev 15 2006-10-29 06:59:59 +0000
@@ -60,10 +56,7 @@ test_expect_success PERL,POSIX_TIMEZONE 'check timestamps with author-specific t
 	user4=User Four <user4@domain.org> MST7MDT,M4.1.0,M10.5.0
 	EOF
 	git cvsimport -p"-x" -A cvs-authors -C module-2 module &&
-	(
-		cd module-2 &&
-		git log --format="%s %ai %an"
-	) >actual-2 &&
+	git -C module-2 log --format="%s %ai %an" >actual-2 &&
 	cat >expect-2 <<-EOF &&
 	Rev 16 2006-10-29 01:00:01 -0600 User Two
 	Rev 15 2006-10-29 01:59:59 -0500 User Two
----- >8 ----------------

-- 
Danh