So my first attempt at using git cherry-pick didn't go so well.
The commit in master looks like

commit ee63981c1fe26299162b9c7f1218d7e3ef802409
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu Sep 23 15:34:56 2010 -0400

Avoid sharing subpath list structure when flattening nested AppendRels.

which is the correct timestamp, but all the back-patched ones look like

commit 4e60212ab5a956bcba89cfd465f945a9c8969f27
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu Sep 23 19:34:56 2010 -0400

Avoid sharing subpath list structure when flattening nested AppendRels.

Apparently somebody's confused between local and GMT time somewhere in
there.

This is with a vanilla build of 1.7.2.3. Anybody else see this type
of symptom?

regards, tom lane

Search Discussions

  • Robert Haas at Sep 23, 2010 at 8:02 pm

    On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane wrote:
    Apparently somebody's confused between local and GMT time somewhere in
    there.
    Ouch. That rather sucks.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • David E. Wheeler at Sep 23, 2010 at 9:20 pm

    On Sep 23, 2010, at 1:02 PM, Robert Haas wrote:
    On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane wrote:
    Apparently somebody's confused between local and GMT time somewhere in
    there.
    Ouch. That rather sucks.
    Obviously, all committers must now relocate to the UK.

    Best,

    David
  • Thom Brown at Sep 23, 2010 at 9:24 pm

    On 23 September 2010 22:20, David E. Wheeler wrote:
    On Sep 23, 2010, at 1:02 PM, Robert Haas wrote:
    On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane wrote:
    Apparently somebody's confused between local and GMT time somewhere in
    there.
    Ouch.  That rather sucks.
    Obviously, all committers must now relocate to the UK.
    Yes, move here. I'll put the kettle on.

    --
    Thom Brown
    Twitter: @darkixion
    IRC (freenode): dark_ixion
    Registered Linux user: #516935
  • Joshua D. Drake at Sep 23, 2010 at 9:27 pm

    On Thu, 2010-09-23 at 22:22 +0100, Thom Brown wrote:
    On 23 September 2010 22:20, David E. Wheeler wrote:
    On Sep 23, 2010, at 1:02 PM, Robert Haas wrote:
    On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane wrote:
    Apparently somebody's confused between local and GMT time somewhere in
    there.
    Ouch. That rather sucks.
    Obviously, all committers must now relocate to the UK.
    Yes, move here. I'll put the kettle on.
    Better add some whiskey buddy... postgresql people can put it down.

    /me looks hard at dpage

    JD

    --
    PostgreSQL.org Major Contributor
    Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
    Consulting, Training, Support, Custom Development, Engineering
    http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
  • Robert Haas at Sep 23, 2010 at 9:36 pm

    On Thu, Sep 23, 2010 at 5:22 PM, Thom Brown wrote:
    On 23 September 2010 22:20, David E. Wheeler wrote:
    On Sep 23, 2010, at 1:02 PM, Robert Haas wrote:
    On Thu, Sep 23, 2010 at 3:52 PM, Tom Lane wrote:
    Apparently somebody's confused between local and GMT time somewhere in
    there.
    Ouch.  That rather sucks.
    Obviously, all committers must now relocate to the UK.
    Yes, move here.  I'll put the kettle on.
    I'm not sure that's the simplest solution to the problem at hand, but
    I'm game...

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Alvaro Herrera at Sep 23, 2010 at 9:51 pm

    Excerpts from Robert Haas's message of jue sep 23 17:36:07 -0400 2010:

    Obviously, all committers must now relocate to the UK.
    Yes, move here.  I'll put the kettle on.
    I'm not sure that's the simplest solution to the problem at hand, but
    I'm game...
    Hey, if it comes to that, I'm game too.

    --
    Álvaro Herrera <alvherre@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Abhijit Menon-Sen at Sep 23, 2010 at 9:31 pm

    At 2010-09-23 15:52:24 -0400, tgl@sss.pgh.pa.us wrote:
    Apparently somebody's confused between local and GMT time somewhere in
    there.

    This is with a vanilla build of 1.7.2.3. Anybody else see this type
    of symptom?
    Not me. I just tried various combinations of commit in one branch and
    cherry-pick in another, and the timestamp stays correct in every case.

    -- ams
  • Tom Lane at Sep 23, 2010 at 9:38 pm

    Abhijit Menon-Sen writes:
    At 2010-09-23 15:52:24 -0400, tgl@sss.pgh.pa.us wrote:
    This is with a vanilla build of 1.7.2.3. Anybody else see this type
    of symptom?
    Not me. I just tried various combinations of commit in one branch and
    cherry-pick in another, and the timestamp stays correct in every case.
    Hm. What git version are you using?

    (I see that 1.7.3 has become the "stable" release since last week,
    so maybe I should update.)

    regards, tom lane
  • Abhijit Menon-Sen at Sep 23, 2010 at 9:46 pm

    At 2010-09-23 17:37:51 -0400, tgl@sss.pgh.pa.us wrote:
    Hm. What git version are you using?
    I'm using 1.7.3, yes. It has a bunch of timezone handling changes, but
    I'm not sure if there's anything related to your problem. If you don't
    have TZ set in your environment, I suppose the following patch *could*
    be relevant, since you're in -0400 and I'm in +0530. I haven't tried
    to verify this, but if cat-file -p on your backported commit shows an
    absurdly high timezone value, then that's the problem.

    Anyway, try 1.7.3 and see if it helps?

    -- ams

    commit 9ba0f0334dd505f78e0374bbe857c5e202f5a778
    Author: Jeff King <peff@peff.net>
    Date: Sun Jul 4 07:00:17 2010 -0400

    parse_date: fix signedness in timezone calculation

    When no timezone is specified, we deduce the offset by
    subtracting the result of mktime from our calculated
    timestamp.

    However, our timestamp is stored as an unsigned integer,
    meaning we perform the subtraction as unsigned. For a
    negative offset, this means we wrap to a very high number,
    and our numeric timezone is in the millions of hours. You
    can see this bug by doing:

    $ TZ=EST \
    GIT_AUTHOR_DATE='2010-06-01 10:00' \
    git commit -a -m foo
    $ git cat-file -p HEAD | grep author
    author Jeff King <peff@peff.net> 1275404416 +119304128

    Instead, we should perform this subtraction as a time_t, the
    same type that mktime returns.

    Signed-off-by: Jeff King <peff@peff.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
  • Tom Lane at Sep 23, 2010 at 10:05 pm

    Abhijit Menon-Sen writes:
    I'm using 1.7.3, yes. It has a bunch of timezone handling changes, but
    I'm not sure if there's anything related to your problem. If you don't
    have TZ set in your environment, I suppose the following patch *could*
    be relevant, since you're in -0400 and I'm in +0530. I haven't tried
    to verify this, but if cat-file -p on your backported commit shows an
    absurdly high timezone value, then that's the problem.
    Well, I do keep TZ set, but anyway an update to 1.7.3 seems like a good
    idea on general principles. Will try it.

    [ experiments a bit ... ] Hm, my Fedora 13 machine isn't showing this
    behavior, even though it's also 1.7.2.3 and I don't see any
    possibly-related patches being carried by Fedora. Odd.

    regards, tom lane
  • Tom Lane at Sep 24, 2010 at 3:23 pm

    I wrote:
    Apparently somebody's confused between local and GMT time somewhere in
    there.
    For the archives' sake: this turns out to be a portability issue not
    handled by the git code. If you are running on a platform old enough
    to have gmtime_r returning int rather than struct tm *, you need this
    patch:

    *** date.c~ Sat Sep 18 19:43:54 2010
    --- date.c Fri Sep 24 10:57:28 2010
    ***************
    *** 406,412 ****
    case '.':
    now = time(NULL);
    refuse_future = NULL;
    ! if (gmtime_r(&now, &now_tm))
    refuse_future = &now_tm;

    if (num > 70) {
    --- 406,412 ----
    case '.':
    now = time(NULL);
    refuse_future = NULL;
    ! if (gmtime_r(&now, &now_tm) == 0)
    refuse_future = &now_tm;

    if (num > 70) {
    ***************
    *** 469,475 ****
    */
    if (num >= 100000000 && nodate(tm)) {
    time_t time = num;
    ! if (gmtime_r(&time, tm)) {
    *tm_gmt = 1;
    return end - date;
    }
    --- 469,475 ----
    */
    if (num >= 100000000 && nodate(tm)) {
    time_t time = num;
    ! if (gmtime_r(&time, tm) == 0) {
    *tm_gmt = 1;
    return end - date;
    }


    [ /me resolves to actually run a program's regression tests before
    assuming it works ]

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 23, '10 at 7:52p
activeSep 24, '10 at 3:23p
posts12
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase