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

From: Jan Hudec <bulb@ucw.cz>
Date: Jul 25, 2007, 20:03 UTC
Message-ID: <20070725200344.GA3808@efreet.light.src>
In-Reply-To: <7vk5sx77me.fsf@assigned-by-dhcp.cox.net>

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

Show 11 quoted lines

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