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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-04-06 05:11:30-0700, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxx/

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

-- 
Danh




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux