| Message ID | 23a4298eababe54ca4b43d7b675b858605d20ec5.1712374021.git.congdanhqx@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | t9604: Fix test for musl libc and new Debian | expand |
Đ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 && > (
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
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 && > > (
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.
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
Đ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.
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 && (
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(-)