Re: Fwd: Re: [PATCH 21.5] Fix signs in time zone string.

Adrian Aichner <[email protected]> Wed, 01 Oct 2014 13:24:48 +0200
Newsgroups gmane.emacs.xemacs.patches
Message-ID <[email protected]>
On 30.09.2014 19:28, Marcus Crestani wrote:
>>>>>> "AA" == Adrian Aichner <[email protected]> writes:
> AA> How could XEmacs and GNU Emacs both be wrong until now?
>
> XEmacs wasn't wrong for long, this caused the problem:
>
> changeset:   5762:427a72c6ee17
> user:        Stephen J. Turnbull <[email protected]>
> date:        Sun Sep 15 23:47:37 2013 +0900
> summary:     Eliminate several compiler (clang) warnings.
>
> diff --git a/src/editfns.c b/src/editfns.c
> --- a/src/editfns.c
> +++ b/src/editfns.c
> @@ -1190,7 +1190,9 @@
>         else if (FIXNUMP (zone))
>          {
>            int abszone = abs (XFIXNUM (zone));
> -         sprintf (tzbuf, "XXX%s%d:%02d:%02d", "-" + (XFIXNUM (zone) < 0),
> +         /* #### I have no idea what this conforms to,
> +            but the compiler has stopped whining. */
> +         sprintf (tzbuf, "XXX%s%d:%02d:%02d", (XFIXNUM (zone) < 0) ? "-" : "+",
>                     abszone / (60*60), (abszone/60) % 60, abszone % 60);
>            tzstring = tzbuf;
>          }
>
> AA> http://git.savannah.gnu.org/cgit/emacs.git/tree/src/editfns.c#n1937
> AA> suggests that they are not including a + character for positive offsets,
> AA> which surprised me.
>
> According to `man tzset', the + character is optional.  I prefer to make
> it explicit to avoid confusion.
>
> AA> But zone offsets > 0 do not include the - sign, which is the same logic
> AA> XEmacs uses before your patch.
>
> No, it is not.  GNU Emacs is correct, but it's implementation is a
> rather hacky array access:  &"-"[XINT (zone) < 0]

I'm glad you said that.

>
> A negative zone offset yields &"-"[1], which skips the minus and yields
> the empty string; a zero or positive zone offset yields the minus via
> &"-"[0].

Sorry for the false alarm. I even went through the steps you describe, 
but I did it wrong.

I guess the ternary expression messed with a brain-half while I went 
through the exercise with the other.

So the encoding has to apply the timezone offset in opposite direction 
to arrive at the UTC value for the encoded time, right?

GNU Emacs, it appears, prefixes 0 with a minus sign as well.

>
> AA> Also, why are you removing the REST argument in passing without mention?
>
> That was a misunderstanding on my part, sorry for that.
>