Re: [RFC PATCH v2] Add 'human' date format

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 11, 2018, 20:49 UTC
Message-ID: <CA+55aFym5aSudSHiVA=VmvoY=WFytUqficLQCE4Sd_urjwKqPw@mail.gmail.com>
In-Reply-To: <CACayv=ifE5BQVtxXCVEhS3uO7iz1z+ZPrF3J_n=e-uoYOpwNtA@mail.gmail.com>

On Wed, Jul 11, 2018 at 1:34 PM Andrei Rybak <rybak.a.v@gmail.com> wrote:

Show 5 quoted lines

>
> > +     int human_tz = -1;
>
> Is -1 an OK initial value for timezone if local_time_tzoffset returns
> negative values as well? It looks like it doesn't matter for from functional

The value was intentionally picked to *not* be a valid timezone value, so that the comparison of "human_tz == tz" would always fail if DATE_HUMAN is not selected.

But it could be anything else invalid, of course. It could be MAX_INT or something like that.

By picking something that isn't possibly a real timezone value, late code can do things like

        hide.tz = local || tz == human_tz;

without worrying about whther it's really DATE_HUMAN or not.

The clearing of "human_tm" is done for a similar reason: the code does

        hide.year = tm->tm_year == human_tm->tm_year;

(and then later just checks "if (human_tm->tm_year)") knowing that a non-zero tm_year will only ever happen for human_tz (and that 1900 is not a valid git date, even though I guess in theory you could do it).

               Linus