Wrong time in git-log when using right/ timezone

Hi,

My timezone is set to right/Europe/Berlin. git-log 1.5.2.2 gives me output such as:

| Date:   Wed Jul 18 16:17:31 2007 +0159

Note the timezone, which should be +0200.

I'm using tzcode/tzdata 2007f from <ftp://elsie.nci.nih.gov/pub/>. A small test script is attached.

Regards, Peter Hartlich

I wrote:

Forgot to add that the bug is present in the current dev version.

Regards, Peter Hartlich

On Wed, 18 Jul 2007, Peter Hartlich wrote:

Wow. I just tried:

	git show --raw --date=local

with TZ=CET and TZ=right/Europe/Berlin respectively.

Trippy.

I get:

	commit 9dfdf14b3805e89aa2782458bda15b3dfae24c09
	Author: Junio C Hamano <gitster@pobox.com>
	Date:   Mon Jul 16 01:41:17 2007

for the CET case, but for right/Europe/Berlin I get:

	commit 9dfdf14b3805e89aa2782458bda15b3dfae24c09
	Author: Junio C Hamano <gitster@pobox.com>
	Date:   Mon Jul 16 01:39:54 2007

ie apparently Berlin is in a timezone of its own that is roughly one minute and 23 seconds away from CET.

What the *heck*?

I really don't think this is git that is confused: I get the exact same thing with "date" too:

	[torvalds@woody git]$ TZ=right/Europe/Berlin date ; TZ=CET date
	Wed Jul 18 18:52:25 CEST 2007
	Wed Jul 18 18:52:48 CEST 2007

so it really *is* the tzdata that says that Berlin is not +0200, and it's not even +0159, it's something really strange with fractional minutes away from UTC.

What can I say? "Those wacky Germans - they have a wonderful sense of humor"?

			Linus

On Wed, 18 Jul 2007, Linus Torvalds wrote:

Well ... not if you compare right/Europe/Berlin vs right/CET

jp3@neutron: ~>TZ=right/CET date '+%H:%M:%S %z'; TZ=right/Europe/Berlin date '+%H:%M:%S %z' 19:49:45 +0200 19:49:45 +0200

but, I suspect that the following is the underlying cause of the problem?

jp3@neutron: ~>TZ=right/UTC date '+%H:%M:%S %z'; TZ=UTC date '+%H:%M:%S %z' 17:51:32 +0000 17:51:55 +0000

Is git working internally in TZ=UTC?

On Wed, 18 Jul 2007, Julian Phillips wrote:

Yes.

The TZ in git terms has no meaning what-so-ever, it's purely for "decoration", so that people can see what the local time was. But a git time really *is* the UTC seconds-since-1970, and the timezone is saved so that it can be shown, but not for anything else.

So git always stores times in UTC, but then when showing them, it shows them as relative to the timezone they were done in.

You can see this by doing

	git cat-file commit HEAD

which shows something like

	author Junio C Hamano <gitster@pobox.com> 1184542877 -0700

and that "1184542877" is literally the time in UTC, and is the only thing that git really tracks. The "-0700" is informational, so that when you show it as a log entry, it shows as

	Author: Junio C Hamano <gitster@pobox.com>
	Date:   Sun Jul 15 16:41:17 2007 -0700

even though that "1184542877" really means "Sun Jul 15 23:41:17 2007".

So git never actually saves anything at all in local time, it just tries to show things in whatever the local time was for the person who did something (unless you use the "--date=local" option, in which case it ignores the saved TZ, and uses your _current_ TZ to show the date)

Unless we have a bug, of course.

			Linus

Linus Torvalds, Wed, Jul 18, 2007 19:01:31 +0200:

Maybe the "right/" timezones are just a little too right?

http://ecos.sourceware.org/ml/libc-alpha/2000-12/msg00068.html

Linus Torvalds <torvalds@linux-foundation.org> writes:

No, I do not think the wackiness is from Germans.

Using right/ perhaps without realizing the differences between TZ=right/Europe/Berlin and TZ=Europe/Berlin is probably the source of confusion.

I do not offhand know what role "leap second adjustment" should play in the context of converting from Unix time we store in git commit objects to human readable role. As far as I understand, the returned timestamp from time(2), which we record in commit objects, is already "leap second adjusted".

On Wed, Jul 18, 2007 at 13:57:13 -0700, Junio C Hamano wrote:

I can attempt a brief explanation if anyone is (still) interested.

Leap seconds are added iregularly, because Earth rotation is slightly
irregular. Therefore some time calculations require lookup into a table of
leap seconds:
 - If you include leap seconds in the timer, converting to date+time does,
   while time difference does not. This is what the right/ timezones use.
 - If you exclude leap seconds from the timer, time difference does, but
   converting to date+time does not. This is what the normal timezones use.

Obviously, the two approaches don't play well together. POSIX chose the later, likely because it's much more common to want to know date+time for some moment, than to calculate several year long time interval with second precision (because so far there have been at most 2 seconds difference per year).

Note, that the former approach allows you to talk about time 65936023 seconds from now, but not what date and time it will be, while the later allows you to talk about 2437-11-05 16:12:05, but not how many seconds are left until than.