threads / bug / 34606

[bug] remotes-hg: timezones are transformed

Subject: [bug] remotes-hg: timezones are transformed

## tl;dr

3 messages between Aug 3, 2013 and Aug 4, 2013.

replies: 2people: 2as markdown or json

Jörn Hees· Aug 3, 2013, 16:36 UTC · lore
Hi,

it seems that if you use the 1.8.3.4 remote-helpers/git-remote-hg to clone a mercurial repo the timezone information of commits gets transformed into your current timezone. (command: git clone hg::…)

I noticed this when a colleague in another timezone used Kiln to also export the same mercurial repo that i had cloned from git before. Fetching from his git repo gives me a "second root tree" with all commits duplicated. A git show of two equivalent commit reveals that the Date: line of the commits changed. Tracking this back into the original mercurial repo reveals that _his_ times are correct.

This will also make two or more clones from different timezones all using the same hg remote repo incompatible!

Example: Original mercurial commit (timezone: -7200 = -4h) https://bitbucket.org/lipis/gae-init/commits/a43078f90e727a13767cf14c740157763fb423b5/raw/

Lipis git export via Kiln: (-4h) https://github.com/lipis/gae-init/commit/36b7cabf03fbba784cc41b63430433e9fc79ca8c

My export via git clone hg::ssh://hg@bitbucket.org/lipis/gae-init (+2h) https://github.com/joernhees/git-hg-remote-bug_gae-init/commit/8341bf10f1f0a7a924717a8a2c1770f61acd51ae

Expected would be that the hashes of both git exports are the same. His are correct as far as i can tell.

Cheers, Jörn

Felipe Contreras· Aug 3, 2013, 23:17 UTC · re: Jörn Hees · lore

Re: [bug] remotes-hg: timezones are transformed

Hi,
On Sat, Aug 3, 2013 at 11:36 AM, Jörn Hees <dev@joernhees.de> wrote:
Show 20 quoted lines
> it seems that if you use the 1.8.3.4 remote-helpers/git-remote-hg to clone a mercurial repo the timezone information of commits gets transformed into your current timezone.
> (command: git clone hg::…)
>
> I noticed this when a colleague in another timezone used Kiln to also export the same mercurial repo that i had cloned from git before.
> Fetching from his git repo gives me a "second root tree" with all commits duplicated.
> A git show of two equivalent commit reveals that the Date: line of the commits changed.
> Tracking this back into the original mercurial repo reveals that _his_ times are correct.
>
> This will also make two or more clones from different timezones all using the same hg remote repo incompatible!
>
>
> Example:
> Original mercurial commit (timezone: -7200 = -4h)
> https://bitbucket.org/lipis/gae-init/commits/a43078f90e727a13767cf14c740157763fb423b5/raw/
>
> Lipis git export via Kiln: (-4h)
> https://github.com/lipis/gae-init/commit/36b7cabf03fbba784cc41b63430433e9fc79ca8c
>
> My export via git clone hg::ssh://hg@bitbucket.org/lipis/gae-init (+2h)
> https://github.com/joernhees/git-hg-remote-bug_gae-init/commit/8341bf10f1f0a7a924717a8a2c1770f61acd51ae
Actually our version is the correct one:

% hg commit -m one -d "2012-04-28 11:28 +0200" % hg export # HG changeset patch # User Felipe Contreras <felipe.contreras@gmail.com> # Date 1335605280 -7200 # Sat Apr 28 11:28:00 2012 +0200

-- 
Felipe Contreras
Jörn Hees· Aug 4, 2013, 13:03 UTC · re: Felipe Contreras · lore

Re: [bug resolved] remotes-hg: timezones are transformed

Hi,
On 4 Aug 2013, at 01:17, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Show 16 quoted lines
> On Sat, Aug 3, 2013 at 11:36 AM, Jörn Hees <dev@joernhees.de> wrote:
> 
>> it seems that if you use the 1.8.3.4 remote-helpers/git-remote-hg to clone a mercurial repo the timezone information of commits gets transformed into your current timezone.
>> (command: git clone hg::…)
>> 
>> I noticed this when a colleague in another timezone used Kiln to also export the same mercurial repo that i had cloned from git before.
>> Fetching from his git repo gives me a "second root tree" with all commits duplicated.
>> A git show of two equivalent commit reveals that the Date: line of the commits changed.
>> Tracking this back into the original mercurial repo reveals that _his_ times are correct.
>> 
>> This will also make two or more clones from different timezones all using the same hg remote repo incompatible!
>> 
>> 
>> Example:
>> Original mercurial commit (timezone: -7200 = -4h)
>> https://bitbucket.org/lipis/gae-init/commits/a43078f90e727a13767cf14c740157763fb423b5/raw/

sorry, i feel stupid for this now… this obviously is -2h: 2*60*60… not 4 (but see below)

>> Lipis git export via Kiln: (-4h)
>> https://github.com/lipis/gae-init/commit/36b7cabf03fbba784cc41b63430433e9fc79ca8c
so is this: it should've said -2h
>> My export via git clone hg::ssh://hg@bitbucket.org/lipis/gae-init (+2h)
>> https://github.com/joernhees/git-hg-remote-bug_gae-init/commit/8341bf10f1f0a7a924717a8a2c1770f61acd51ae
this one was correct: +2h
Show 8 quoted lines
> Actually our version is the correct one:
> 
> % hg commit -m one -d "2012-04-28 11:28 +0200"
> % hg export
> # HG changeset patch
> # User Felipe Contreras <felipe.contreras@gmail.com>
> # Date 1335605280 -7200
> #      Sat Apr 28 11:28:00 2012 +0200

Thanks for clarifying this. I had falsely assumed that no one would dare to flip the sign of the timezone spec. Turns out that mercurial commits contain the _negative_ timezone offset in seconds, so UTC+2 will actually be saved as -7200! I was actually still doubtful so i searched for some credible ref and was able to find this insanity documented in "hg help dates":

Show 6 quoted lines
> - "1165432709 0" (Wed Dec 6 13:18:29 2006 UTC)
> 
>     This is the internal representation format for dates. The first number is
>     the number of seconds since the epoch (1970-01-01 00:00 UTC). The second
>     is the offset of the local timezone, in seconds west of UTC (negative if
>     the timezone is east of UTC).

I use the word insane here, as there are many standards for date times, but not one dares to switch the timezone sign! https://en.wikipedia.org/wiki/Time_zone https://upload.wikimedia.org/wikipedia/commons/a/ad/Standard_time_zones_of_the_world.png

I'm sorry for reporting this as a bug and instead have to pull my hat.

Cheers, Jörn

← back to recent threads