All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Đoàn Trần Công Danh" <congdanhqx@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] t9604: Fix test for musl libc and new Debian
Date: Sun, 7 Apr 2024 08:45:38 +0700	[thread overview]
Message-ID: <ZhH6wq5eTUTZS_zE@danh.dev> (raw)
In-Reply-To: <20240407013312.GD1085004@coredump.intra.peff.net>

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

  reply	other threads:[~2024-04-07  1:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-06  3:29 [PATCH] t9604: Fix test for musl libc and new Debian Đoàn Trần Công Danh
2024-04-06 12:11 ` Junio C Hamano
2024-04-07  1:38   ` Đoàn Trần Công Danh
2024-04-08 17:34     ` Junio C Hamano
2024-04-07  1:33 ` Jeff King
2024-04-07  1:45   ` Đoàn Trần Công Danh [this message]
2024-04-07  1:50     ` Đoàn Trần Công Danh
2024-04-10  3:28 ` [PATCH v2] " Đoàn Trần Công Danh
2024-04-10  3:29   ` Eric Sunshine
2024-04-10  3:35   ` Đoàn Trần Công Danh
2024-04-10  3:37   ` Eric Sunshine
2024-04-10  7:10     ` Đoàn Trần Công Danh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZhH6wq5eTUTZS_zE@danh.dev \
    --to=congdanhqx@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.