On Saturday, July 7, 2018 3:02:35 PM MST Linus Torvalds wrote:
> From: Linus Torvalds
>
> This adds --date=human, which skips the timezone if it matches the
> current time-zone, and doesn't print the whole date if that matches (ie
> skip printing year for dates that are "this year", but also skip
On Tue, Jul 24, 2018 at 2:49 PM Junio C Hamano wrote:
>
> But lack of TZ does not give me enough hint about which content it
> happened. The fact that this was done late at night on weekend is
> indeed interesting, and I may not care what time it locally was for
> me, so perhaps this is an intend
Linus Torvalds writes:
> From: Linus Torvalds
>
> This adds --date=human, which skips the timezone if it matches the
> current time-zone, and doesn't print the whole date if that matches (ie
> skip printing year for dates that are "this year", but also skip the
> whole date itself if it's in the
On Wed, Jul 11, 2018 at 2:24 PM Ævar Arnfjörð Bjarmason
wrote:
>
> I think that's true for the likes of linux.git & git.git, but a lot of
> users of git say work in some corporate setting entirely or mostly in
> the same timezone.
>
> In that case, knowing if some commit whose sole message was "fi
[ Trying to come up with crazy special cases ]
On Wed, Jul 11, 2018 at 1:49 PM Linus Torvalds
wrote:
>
> But it could be anything else invalid, of course. It could be MAX_INT
> or something like that.
That might be better. A timezone of -1 isn't actually a valid
timezone, but I guess you could c
On Sat, Jul 07 2018, Linus Torvalds wrote:
I really like where this is going in general. Having a "human" format
would be great.
> For really recent dates (same day), use the relative date stamp, while
> for old dates (year doesn't match), don't bother with time and timezone.
> [...]
> Once you
Andrei Rybak writes:
> On Wed, 11 Jul 2018 at 22:34, Andrei Rybak wrote:
>>
>> 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
>>
>
> meant to say: "It looks like it doesn't matter from the func
On Wed, Jul 11, 2018 at 1:34 PM Andrei Rybak wrote:
>
> > + 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 timezo
On Wed, 11 Jul 2018 at 22:34, Andrei Rybak wrote:
>
> 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
>
meant to say: "It looks like it doesn't matter from the functional
point of view".
On 2018-07-08 00:02, Linus Torvalds wrote:
> diff --git a/date.c b/date.c
> index 49f943e25..4486c028a 100644
> --- a/date.c
> +++ b/date.c
> @@ -77,22 +77,16 @@ static struct tm *time_to_tm_local(timestamp_t time)
> }
>
> /*
> - * What value of "tz" was in effect back then at "time" in the
> - *
From: Linus Torvalds
This adds --date=human, which skips the timezone if it matches the
current time-zone, and doesn't print the whole date if that matches (ie
skip printing year for dates that are "this year", but also skip the
whole date itself if it's in the last few days and we can just say
11 matches
Mail list logo
