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, 22:20 UTC
Message-ID
<201103212320.11336.jnareb@gmail.com>
In-Reply-To
<4D879B70.8070405@eaglescrag.net>
J.H. wrote:
> On 03/21/2011 09:01 AM, Jakub Narebski wrote:
Show 11 quoted lines
> > 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).
> 
> The implementation I have running in the back of my head would be
> completely independent, so I'm not sure what implementation you are
> thinking of that would cause this.  One of the reasons I'm suggesting
> Javascript at all is to avoid exactly this problem.
Well, of course if output is the same, only post-processed by JavaScript
(and no server-side fallback), then there is no interference between
timezones and output caching.
 
N.B. caching of git output, or of parsed data, allows to generate multiple
outputs from one cached value... but OTOH output caching is simpler.
[...]
Show 15 quoted lines
> > Well, if we are doing it on server side, then by having 'timezone' feature
> > rather than 'localtime' one from Kevin patches, we would have per-repo
> > configuration "for free".
> 
> Doing it on the server overly complicates things, breaks web caches,
> gitweb-caching and generally I'd argue is not what we want.  It would
> work for small installations, in particular those not using
> gitweb-caching, but honestly this is a useful enough feature for a more
> distributed audience it needs to work with gitweb-caching, without
> putting undue burden on the caching engine (as a whole).  Javascript is
> the obvious, and simple answer to that.  Won't add any substantial
> complexity to the backend, and will allow for more complex choices and
> instant changes (without involving the backend at all).
> 
> That pretty much sounds like a win to me anyway...

Note that proposed "on server" solution, like the one in Kevin's patches, would not include a way to select a way of presenting dates by client: it all would be set on server, and not interfere with output caching.

As to complexity: you would either have complexity in backend, or complexity in JavaScript...

But I agree that JavaScript enhancement solution is better.
Show 12 quoted lines
> > > I would think, if we are doing this in JavaScript, that this is an over
> > > complication to do on a per-repo basis.  I would guess setting a generic
> > > default and letting people deviate makes more sense.  Just my thought
> > > anyway, but I think there's a lot of extra per-repo configurations that
> > > add complexity with minimal gain.
> > 
> > It it is set _by client_, then of course it doesn't make much sense to
> > make it configurable per-repository.  Besides it would be difficult to
> > implement and store in JavaScript, I think.
> 
> Cookies solve the problem, and those are basically trivial to deal with
> in Javascript.
I was talking about difficulty of _per-repo_ configuration with 
_client-side_ scripting.  For each [visited] repository we would have to
store config: too much for a cookie (well, perhaps localStorage... ;-)).
Show 6 quoted lines
> > Per-repository settings makes sense for _server-side_; different 
> > repositories may have different character: some might be geographically
> > distributed, some might have all contributors in single timezone.
> 
> Agreed, since I've been arguing for the client side work, I think we are
> on the same page here.
[...]
> Also keeping in mind that miroformats are almost explicitly for the
> benefit of search engines, which I'm not sure if a majority of gitweb
> installations care about, it may not be worthwhile to actually go down
> that road.
Right.
Show 22 quoted lines
> > > > 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.
> > >
> > > I wasn't intending to change the current formatting of the times we have
> > > in place currently.  Just allowing people to change what time was being
> > > displayed.
> > 
> > I wanted to say that JavaScript post-processing of dates is a bit 
> > orthogonal to David's server-side localtime (or similar) feature.
> 
> It's a different direction, yes, but it's definitely not orthogonal.  If
> you do this on the server side, as David originally suggested, you can
> create a mess in other places (external proxies, external web caches,
> gitweb-caching, etc).  I like his idea, just not where it's implemented
> at current.  If you leave the server side alone, and deal with the
> processing of the dates on the client side you alleviate all of the
> server side gotchas, while only introducing one or two gotchas to the
> client side.
> 
> This isn't an orthogonal discussion, it's a discussion of where the
> right place / right solution to accomplish the same goal is.
Well, perhaps it is not orthogonal discussion, but you can those two
_slightly different_ solutions:
 * server-side, per-repository config, no client choice
 * client-side, JavaScript enhancements, global per-client choice,
   client choice stored in cookie
might work together... though it probably doesn't make much sense.
-- 
Jakub Narebski
Poland
Previous: J.H.Next: John 'Warthog9' Hawley
Message 16 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.