git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jakub Narebski <jnareb@gmail.com>
Date
Mar 21, 2011, 00:20 UTC
Message-ID
<201103210120.50337.jnareb@gmail.com>
In-Reply-To
<4D8681CF.3060005@eaglescrag.net>
On Sun, 20 Mar 2011, J.H. wrote:
Show 10 quoted lines
> > 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.
 
> 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.

Kevin's patch assumes that geographically concentrated project means all or almost all commits are generated "in office" and use the same timezone, which is a timezone of a project.

Currently there is no way to specify _project_ timezone. Perhaps instead of 'localtime' feature, which since v2 means also per-project `gitweb.localtime' configuration variable, we would allow for `gitweb.timezone' configuration variable, which can be "gmt", "utc", or "localtime" (meaning local to author / committer / tagger).

What do you think?
Show 5 quoted lines
> 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.

Single timezone (currently GMT/UTC, perhaps made configurable, perhaps made client local via JavaScript) is good to compare dates. Author local time is good to notice "atnight" commits.

[...]
Show 5 quoted lines
> > 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.
[...]
Show 21 quoted lines
> 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
We can use what microformats use for date, i.e. 1997-07-16T19:20:30+01:00
or 1997-07-16T19:20:30+0100, in 'date' or 'title' attribute (with 
appropriate microformat class)... or we can use raw git date, i.e. epoch
plus numerical timezone.
 
Note that JavaScript mangling of dates is quite independent on whether
dates are displayed in GMT/UTC or in author / committer / tagger timezone
like for current 'localtime' feature.
Show 9 quoted lines
> 	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)

Hmmm... we could also automatically update relative dates to reflect passing of time ;-)

Show 19 quoted lines
> 	   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.
Note that we would have to write this JavaScript code...
-- 
Jakub Narebski
Poland
Previous: Kevin CernekeeNext: J.H.
Message 11 of 36 in “gitweb: rename parse_date() to format_date()”
  1. 1/2 gitweb: rename parse_date() to format_date()Kevin Cernekee, Mar 19, 2011
  2. 2/2 gitweb: introduce localtime featureKevin Cernekee, Mar 19, 2011
  3. Jakub NarebskiMar 19, 2011
  4. Junio C HamanoMar 19, 2011
  5. Kevin CernekeeMar 19, 2011
  6. Jakub NarebskiMar 19, 2011
  7. Kevin CernekeeMar 19, 2011
  8. Jakub NarebskiMar 19, 2011
  9. J.H.Mar 20, 2011
  10. Kevin CernekeeMar 20, 2011
  11. Jakub NarebskiMar 21, 2011
  12. J.H.Mar 21, 2011
  13. Jakub NarebskiMar 21, 2011
  14. Piotr KrukowieckiMar 21, 2011
  15. J.H.Mar 21, 2011
  16. Jakub NarebskiMar 21, 2011
  17. 0/1 Gitweb: Change timezoneJohn 'Warthog9' Hawley, Mar 24, 2011
  18. 1/1 gitweb: javascript ability to adjust time based on timezoneJohn 'Warthog9' Hawley, Mar 24, 2011
  19. Kevin CernekeeMar 24, 2011
  20. J.H.Mar 24, 2011
  21. Jakub NarebskiMar 24, 2011
  22. Jakub NarebskiMar 24, 2011
  23. Kevin CernekeeMar 24, 2011
  24. J.H.Mar 24, 2011
  25. J.H.Mar 24, 2011
  26. Jakub NarebskiMar 24, 2011
  27. Jakub NarebskiMar 24, 2011
  28. gitweb: Fix handling of fractional timezones in parse_dateJakub Narebski, Mar 25, 2011
  29. Kevin CernekeeMar 25, 2011
  30. gitweb: Fix handling of fractional timezones in parse_dateJakub Narebski, Mar 25, 2011
  31. Junio C HamanoMar 25, 2011
  32. Jakub NarebskiMar 25, 2011
  33. gitweb: Fix handling of fractional timezones in parse_dateJakub Narebski, Mar 25, 2011
  34. Jakub NarebskiMar 19, 2011
  35. Jon SeymourMar 19, 2011
  36. Junio C HamanoMar 19, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.