Re: [PATCH v4 2/2] gitweb: introduce localtime feature

["J.H." <warthog9@eaglescrag.net>]

Hey all,

Sorry for not jumping in on this earlier, too much travel / real world
going on here the past couple of weeks.

> With this feature enabled, all timestamps are shown in the local
> timezone instead of GMT.  The timezone is taken from the appropriate
> timezone string stored in the commit object.

I'd argue there are two types of "local" time that anyone using gitweb
would be looking for (particularly if this is called local time)

1) Time Local to the observer:  Specifically I don't care where every
other commit has taken place, I want to know what time it was in my
preferred time zone (local time zone likely)

2) Time local to the project:  There will be instances where a project
is based in a specific time zone (home office perhaps?) and you will
want to see the commits from that perspective.

The patch itself (as a commit in gitweb) shows the time + TZ (which is
somewhat useful), but there is something quite useful about the rest of
gitweb only handling a single timezone (GMT/UTC) from the backend (I'll
come back to this point), if for no other reason it makes for uniform
handling of time overall.

> This improves usability if the majority of a project's contributors are
> based in a single office, all within the same timezone.  It also makes
> the interface more friendly to non-developers who may need to track
> updates, such as program managers and supervisors.

I'd agree, having multiple different timezones, or trying to think in
UTC/GMT when your not used to it is a pain, and is a valid use case of
gitweb.

> This change does not affect relative timestamps (e.g. "5 hours ago"),
> nor does it affect 'patch' and 'patches' views which already use
> localtime because they are generated by "git format-patch".

Agreed.

> 
> Affected views include:
> * 'summary' view, "last change" field (commit time from latest change)
> * 'log' view, author time
> * 'commit' and 'commitdiff' views, author/committer time
> * 'tag' view, tagger time
> 
> In the case of 'commit', 'commitdiff' and 'tag' views, gitweb used to
> print both GMT time and time in timezone of author/tagger/committer:
> 
>    Fri, 18 Mar 2011 01:28:57 +0000 (18:28 -0700)
> 
> With localtime enabled, the times will be swapped:
> 
>    Thu, 17 Mar 2011 18:28:57 -0700 (01:28 +0000)
> 
> Local times between 00:00 and 05:59, inclusive, will still be printed
> in red ("atnight" style) in these views.

Ok, while I agree with the use case(s) I think the solution is barking
up completely the wrong tree.  My basic complaint is that this is a
change that effects the backend and ties the backend to a specific TZ,
when this is a front facing / client issue.

While I don't always like JavaScript, this is a situation where I think
it would be a much better solution than doing some extensive changes to
time handling in gitweb.

Basically the change would leave things alone should this be disabled
(you are already doing this, which is good), however should this be
enabled a couple of minor things change:

	1) By default gitweb will continue to display things in UTC.
	   This is a good fallback, and a reasonably safe thing to do
	   should someone have JavaScript disabled.  The reality is
	   most users with it disabled will know or understand what to
	   do with UTC times

	2) Keep the original TZ marked in the html, somewhere hidden on
	   the page is fine

	3) Once a page is loaded attempt to execute the Javascript,
	   which will just cycle through the page and update the Date /
	   Times based on a set of possible (though user choosable
	   options):
		- Local Time (could easily default to this and
		  JavaScript can detect that from the browser)
		- Specific Timezone
		- Default / UTC
		- Original Timezone (from author / commit)

	   Could easily include the original timestamp / utc if
	   Javascript modifies it.  Easy enough to just automatically
	   store the choice (should one be made) in a cookie in the
	   browser, and give the maintainer of the site and easy way
	   to set a rational default given their specific environment.

The obvious advantages:
	- Doesn't give weird data to people behind caching proxies
	- Ability for people working diverse timezones to see things
	  in their local time zone pretty trivially
	- If a site is using gitweb-caching they can take advantage
	  of the feature
	- Won't break bots / scripts that may be crawling the pages or
	  reading the rss feeds (because the timestamps will all be the
	  same assuming it doesn't try to render the javascript)

If you are interested I can bang that out tomorrow (shouldn't take
long), but I would *MUCH* rather see this done via JavaScript than to
muddy up the backend with multiple timezones and such.

- John 'Warthog9' Hawley