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

From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
Date: Mar 21, 2011, 18:39 UTC
Message-ID: <AANLkTi=E7fahZ9rnO2-bq=Jo7eVnimkFkcMR_=FdtBN9@mail.gmail.com>
In-Reply-To: <201103211701.01785.jnareb@gmail.com>

On Mon, Mar 21, 2011 at 5:01 PM, Jakub Narebski <jnareb@gmail.com> wrote:

Show 33 quoted lines

> On Mon, 21 Mar 2011 at 03:35, J.H. wrote:
>> On 03/20/2011 05:20 PM, Jakub Narebski wrote:
>>> On Sun, 20 Mar 2011, J.H. wrote:
>>>
>>>>> 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)
>>>
>>> This can be done only via JavaScript, otherwise how would you get user's
>>> timezone?  Well, you could specify timezone via a form, save it in
>>> a cookie and do conversion to timezone from cookie on server... but this
>>> means more code, and would screw up with output caching if/where
>>> implemented.
>>
>> I think this would screw up less caching vs. more caching w/ Javascript.
>> Without doing this with Javascript having any hard coded timezone like
>> what's proposed here is bad, particularly if for some reason two people
>> can select different time zones for whatever reason (not an unreasonable
>> extension of what's been proposed)
>
> First, it would complicate caching, as output would depend not only purely
> on URL, but can also depend on cookies.  Cache key would have to take it
> into account.
>
> Second, it would reduce effectiveness of cache, as single page would have
> to have multiple versions (up to 24, one per timezone, I guess).

It would reduce the effectiveness only if it's really needed. If everyone works from one timezone, the cache have only one version. Only if there are users from multiple timezones, which means the feature is really required, the cache would have multiple versions.

In my case we have main office in one place, but we get commits from several other timezones. So although the "one timezone for project" would benefit most people, some might still not be very happy.

-- 
Piotr Krukowiecki