Linus Torvalds [off-list ref] 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".
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 [off-list ref]