Wrong time in git-log when using right/ timezone

Wrong time in git-log when using right/ timezone

[Peter Hartlich]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

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

[-- Attachment #2: tz.sh --]
[-- Type: application/x-sh, Size: 282 bytes --]

Re: Wrong time in git-log when using right/ timezone

[Peter Hartlich]

I wrote:

> git-log 1.5.2.2 gives me output such as:

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

Regards,
Peter Hartlich

Re: Wrong time in git-log when using right/ timezone

[Linus Torvalds]

On Wed, 18 Jul 2007, Peter Hartlich wrote:
> 
> 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.

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

Re: Wrong time in git-log when using right/ timezone

[Julian Phillips]

On Wed, 18 Jul 2007, Linus Torvalds wrote:

> 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.

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?

-- 
Julian

  ---

Homer:	We always have one good kid and one lousy kid.  Why can't both
 	our kids be good?

Marge:	We have three kids, Homer.

 		   Separate Vacations

Re: Wrong time in git-log when using right/ timezone

[Linus Torvalds]

On Wed, 18 Jul 2007, Julian Phillips wrote:
> 
> Is git working internally in TZ=UTC?

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

Re: Wrong time in git-log when using right/ timezone

[Alex Riesen]

Linus Torvalds, Wed, Jul 18, 2007 19:01:31 +0200:
> 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*?
> 

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

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

Re: Wrong time in git-log when using right/ timezone

[Junio C Hamano]

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

> Wow. I just tried:
>
> 	git show --raw --date=local
>
> with TZ=CET and TZ=right/Europe/Berlin respectively.
> ...
> 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"?

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".

Re: Wrong time in git-log when using right/ timezone

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

On Wed, Jul 18, 2007 at 13:57:13 -0700, Junio C Hamano wrote:
> 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".

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.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]