From: Jeff King <peff@peff.net>
To: Chris Rorvick <chris@rorvick.com>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
Date: Fri, 2 Nov 2012 05:43:00 -0400 [thread overview]
Message-ID: <20121102094259.GA28414@sigill.intra.peff.net> (raw)
In-Reply-To: <CAEUsAPb7hUViLn7V7v65r6mOqRHr+180ynRX8K9t3nuJVyePfg@mail.gmail.com>
On Thu, Nov 01, 2012 at 08:12:20PM -0500, Chris Rorvick wrote:
> > Just FYI, t9604-cvsimport-timestamps.sh is still failing for me.
> >
> > I haven't spent too long on this yet, but I had hoped that setting
> > TZ would sidestep any DST issues. (I have downloaded new tzdata, but
> > have yet to install - actually I don't really want to!). It is not
> > clear from the tzset manpage what happens if you use the DST format
> > for TZ, but you don't provide the start/end date for DST, which is
> > what this test is doing.
> >
> > Perhaps the test should use the non-DST format? e.g. "TZ=CST6 git ..."
> > Does the test really care about DST? (*if* that is indeed the problem).
>
> It actually looks like your TZ database is fine and the problem is
> with the conversion to a struct tm. In each case, the time is
> localized to the previous TZ value while the offset for the current TZ
> value. For example, look at the first commit in the first test. It
> converted the timestamp to 18:00 (CST6) while all the rest came
> through as expected. I suspect the previous version of cvsimport
> would exhibit similar behavior with the first imported commit. What
> is your platform?
Yeah, I think that is it. IIRC, Ramsay is on cygwin, and I noticed this
in perl 5.16's POSIX.xs:
#ifdef WIN32
/*
* (1) The CRT maintains its own copy of the environment, separate from
* the Win32API copy.
*
* (2) CRT getenv() retrieves from this copy. CRT putenv() updates this
* copy, and then calls SetEnvironmentVariableA() to update the Win32API
* copy.
*
* (3) win32_getenv() and win32_putenv() call GetEnvironmentVariableA() and
* SetEnvironmentVariableA() directly, bypassing the CRT copy of the
* environment.
*
* (4) The CRT strftime() "%Z" implementation calls __tzset(). That
* calls CRT tzset(), but only the first time it is called, and in turn
* that uses CRT getenv("TZ") to retrieve the timezone info from the CRT
* local copy of the environment and hence gets the original setting as
* perl never updates the CRT copy when assigning to $ENV{TZ}.
*
* Therefore, we need to retrieve the value of $ENV{TZ} and call CRT
* putenv() to update the CRT copy of the environment (if it is different)
* whenever we're about to call tzset().
[...]
I wonder if Ramsay has an older perl that does not do this special
hackery right. I'll see if I can dig up where it first appeared.
-Peff
next prev parent reply other threads:[~2012-11-02 9:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-29 10:21 What's cooking in git.git (Oct 2012, #09; Mon, 29) Jeff King
2012-11-01 18:40 ` Ramsay Jones
2012-11-02 1:12 ` Chris Rorvick
2012-11-02 9:43 ` Jeff King [this message]
2012-11-02 9:56 ` Jeff King
2012-11-02 21:33 ` Ramsay Jones
2012-11-04 12:29 ` Jeff King
2012-11-10 18:33 ` Ramsay Jones
2012-11-11 17:41 ` Jeff King
2012-11-13 18:47 ` Ramsay Jones
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=20121102094259.GA28414@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=chris@rorvick.com \
--cc=git@vger.kernel.org \
--cc=ramsay@ramsay1.demon.co.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).