Re: [Bug] git-log prints wrong unixtime with --date=format:%s

[Michael Heerdegen]

Jeff King  writes:

> Oh, I agree that unix times are handy. I just think that "use %at in the
> pretty-format, instead of %ad and then %s in the date-format" is not
> such a bad workaround.

I had missed %at (and %ct).  Yes, works perfectly - thanks for the hint.


Regards,

Michael.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

[Michael Heerdegen]

Jeff King  writes:

>   3. The epoch times for the latter lines should match.

FWIW, I think the epoch time is the most practical way to transfer the
time of a commit into a different program.  When this program wants to
do it's own date arithmetic with it, unix time is just nice (no time
format parsing needed).

That's why it would be good if the unix time values could be relied on.

Conclusion: in addition to 3., I wished both epoch times were also
correct per se.


Regards,

Michael.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

[Michael Heerdegen]

Jeff King  writes:

> This is probably a totally separate issue, as it would not be using
> strftime (or IIRC, any of the standard time functions at all). Do you
> have a detailed example that shows the problem?

Ok, this was probably false alarm.  Magit (An Emacs Git front end) shows
rounded duration values (rounded hours in my case) in its log views, I
think I just got confused because of this.  In my tests now, the results
were as expected.


Thanks,

Michael.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

[Michael Heerdegen]

Michael Heerdegen <michael_heerde...@web.de> writes:

> the command
>
>git log --pretty=format:%ad --date=format:%s
>
> displays wrong unixtime values; apparently how much the printed value
> differs from the expected value depends on the system's time zone and
> whether daylight savings time is enabled or not.

Two more comments:

  - --date=raw seems to work correctly (though the doc tells it would
also use "%s").

  - When specifying versions like @{N hours}, the result seems to differ
(by one hour?) from what I expect, too.


Thanks,

Michael.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug] git-log prints wrong unixtime with --date=format:%s

[Michael Heerdegen]

Hello,

the command

   git log --pretty=format:%ad --date=format:%s

displays wrong unixtime values; apparently how much the printed value
differs from the expected value depends on the system's time zone and
whether daylight savings time is enabled or not.

Here is a reproducible recipe compiled by Yuri Khan who helped me
localizing the problem and whom I CC'd:

0. Versions

$ git --version
git version 2.8.2

$ dpkg -l tzdata | tail -1
ii  tzdata  2016d-0ubuntu0.16.04 all  time zone and
daylight-saving time data

1. Initialize an empty Git repository:

$ git init test
$ cd test

2. Make a commit, using the Europe/Berlin time zone:

$ TZ=Europe/Berlin git commit -m 'test' --allow-empty

3. Examine the timestamp recorded in the commit object:

$ git cat-file -p HEAD | grep author
author Yuri Khan  1463260938 +0200

4. Check that it corresponds to the current time:

$ date +%s
1463260977

5. Try to get the commit date in the unixtime format:

$ TZ=Europe/Berlin git log --pretty=format:%ad --date=format:%s -1

Expected result: 1463260938 (same as recorded in the commit object).
Observed result: 1463264538 (3600s = one hour ahead).

For lulz, use another time zone:

$ TZ=Asia/Novosibirsk git log --pretty=format:%ad --date=format:%s -1

Expected result: 1463260938 (unixtime is always UTC and should not
depend on TZ).
Observed result: 1463246538 (-14400s = 4 hours behind).

Not even specifying the UTC time zone helps:

$ TZ=UTC git log --pretty=format:%ad --date=format:%s -1

Expected result: still 1463260938.
Observed result: 1463268138 (7200s = 2 hours ahead).


FWIW, personally I have not bound the TZ environment variable, my time
zone is constantly that of Berlin, currently CEST.

Many thanks in advance,


Michael.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html