gitweb: rename parse_date() to format_date()

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.

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.

gitweb/gitweb.perl +0 -1

@@ -3928,22 +3945,48 @@ sub git_print_section {
 	print $cgi->end_div;
 }
 
-sub print_local_time {

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.

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.

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".

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.

Quoted 3 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)

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.

Quoted 3 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.

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.

Quoted 10 lines · J.H.

Quoted 3 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.

Quoted 3 lines

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?

Quoted 5 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.

[...]

Quoted 5 lines

Quoted 3 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.

[...]

Quoted 19 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

Quoted 2 lines

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.

Quoted 9 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 ;-)

Quoted 16 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)

Quoted 3 lines

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...

Quoted 13 lines · Jakub Narebski

Quoted 10 lines · J.H.

Quoted 3 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)

Quoted 5 lines

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)

Quoted 14 lines

Quoted 3 lines

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).

Quoted 1 line

What do you think?

Not specifically thinking of setting a per-repo timezone, when I was thinking of "project" I was thinking of the entire gitweb install (I.E. git.kernel.org as a project or pkgs.fedoraproject.org or drupal.org as a project)

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.

Quoted 13 lines

Quoted 12 lines

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

Quoted 4 lines

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.

Well we already have the time in the html, it's just the original TZ that would need to get added. Though it's still likely easier to store the timestamp + tz than use the microformats in the JS.

Quoted 3 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.

Quoted 10 lines

Quoted 9 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)

Quoted 2 lines

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

Yup, which could also go into changing the "22 minutes ago" kind of stuff in real time (beyond just dates). Bonus to cached pages.

Quoted 20 lines · J.H.

Quoted 13 lines · Jakub Narebski

Quoted 10 lines · J.H.

Quoted 3 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)

Quoted 5 lines

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.

Quoted 5 lines

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).

Quoted 16 lines

Quoted 15 lines

Quoted 3 lines

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?

Quoted 4 lines

Not specifically thinking of setting a per-repo timezone, when I was thinking of "project" I was thinking of the entire gitweb install (I.E. git.kernel.org as a project or pkgs.fedoraproject.org or drupal.org as a project)

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".

Quoted 5 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.

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.

[...]

Quoted 13 lines

Quoted 13 lines

Quoted 12 lines

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

Quoted 8 lines

Quoted 4 lines

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.

Well we already have the time in the html, it's just the original TZ that would need to get added. Though it's still likely easier to store the timestamp + tz than use the microformats in the JS.

I agree that epoch + timezone should be easier to manipulate in JavaScript than ISO-8601 or similar format... I think. Note that at least with epoch timezone is necessary only if you want to display date in author etc. zone; if you want to use client (web browser) timezone, it is not necessary.

Note that _where and how_ timestamp is stored for JavaScript manipulation would become gitweb API as much as its links are. I wonder if HTML5 says anything on attribute values used for machine-readable data; microformats site says that using "title" for non human-readable stuff is deprecated for accessibility reasons.

Quoted 7 lines

Quoted 3 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.

Quoted 10 lines

Quoted 10 lines

Quoted 9 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)

Quoted 5 lines

Quoted 2 lines

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

Yup, which could also go into changing the "22 minutes ago" kind of stuff in real time (beyond just dates). Bonus to cached pages.

...though this should probably made it into separate commit.

Quoted 4 lines · Jakub Narebski

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.

Quoted 2 lines

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.

Quoted 3 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...

Quoted 6 lines

Quoted 5 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.

Quoted 3 lines

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.

Quoted 3 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.

Quoted 10 lines

Quoted 7 lines

Quoted 3 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.

Quoted 20 lines · J.H.

Quoted 13 lines · Jakub Narebski

Quoted 10 lines · J.H.

Quoted 3 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)

Quoted 5 lines

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.

Quoted 5 lines

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).

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.

- Local Time (could easily default to this and JavaScript can detect that from the browser)

- 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.

gitweb/gitweb.perl +24 -2

+# Returns an RFC 2822 timestamp string, which may contain HTML.
+# If $use_localtime is 0, don't do anything special.
+# If $use_localtime is 1, add an alternate HH:MM timestamp in parentheses at
+# the end.  If $feature{'localtime'} is enabled this looks like:
+#   Thu, 17 Mar 2011 18:28:57 -0700 (01:28 +0000)
+# Otherwise, it looks like:
+#   Fri, 18 Mar 2011 01:28:57 +0000 (18:28 -0700)
+# If $use_localtime is 1, this will also apply the "atnight" style to
+# local times between 00:00 and 05:59.
+sub timestamp_html {
+	my %date = %{$_[0]};
+	my $use_localtime = $_[1];
+	my $timestamp;
+	my $alt_time;
+
+	if (gitweb_check_feature('localtime')) {
+		$timestamp = $date{'rfc2822_local'};
+		if ($use_localtime && $date{'hour_local'} < 6) {
+			$timestamp = "<span class=\"atnight\">" .
+			             $timestamp .
+			             "</span>";
+		}
+		$alt_time = sprintf(" (%02d:%02d %s)",
+		                    $date{'hour'}, $date{'minute'}, "+0000");
 	} else {
-		$localtime .= sprintf(" (%02d:%02d %s)",
-			$date{'hour_local'}, $date{'minute_local'}, $date{'tz_local'});

# Outputs the author name and date in long form

gitweb/gitweb.perl +1 -4

@@ -3956,10 +3999,9 @@ sub git_print_authorship {
 	my %ad = format_date($co->{'author_epoch'}, $co->{'author_tz'});
 	print "<$tag class=\"author_date\">" .
 	      format_search_author($author, "author", esc_html($author)) .
-	      " [$ad{'rfc2822'}";
-	print_local_time(%ad) if ($opts{-localtime});
-	print "]" . git_get_avatar($co->{'author_email'}, -pad_before => 1)
-		  . "</$tag>\n";
+	      " [" . timestamp_html(\%ad, 0) . "] ".
...
 # Outputs table rows containing the full author or committer information,

Looks like we used to only paint HH:MM part but...
... we now paint the whole line, which I personally think is a friendly move for color challenged people (me included---a larger span of text painted in different colors tends to help you still notice it better using value/brightness difference, even if your hue perception is weaker than other people). But it is a change from the old behaviour and might be worth stating in the log message.

Quoted 5 lines

-     return $localtime;
+     if ($use_localtime) {
+             $timestamp .= $alt_time;
+     }

You kept -localtime nobody uses?

While I don't agree with Jakub about the presense / absence of "[]" around it (that is not a part of "timestamp", but is how the caller wants to prepare the space to plug a timestamp string in), I do agree that the second parameter "use-localtime" looks funny, not because it is an unnamed parameter (which I personally think is fine) but because it isn't about the localness of the displayed time anymore.  Your 'localtime' feature alone controls in which timezone the timestamp is shown, and this only controls the use of 'atnight' highlighting. The parameter needs to be renamed, and perhaps you may clarify it further by making it a keyword argument as Jakub suggests.

Quoted 7 lines · Junio C Hamano

Looks like we used to only paint HH:MM part but...
... we now paint the whole line, which I personally think is a friendly move for color challenged people (me included---a larger span of text painted in different colors tends to help you still notice it better using value/brightness difference, even if your hue perception is weaker than other people). But it is a change from the old behaviour and might be worth stating in the log message.

For the $feature{'localtime'} disabled case, the coloring is the same as before.

I will paint the whole line in the next spin, and mention it in the commit message.

$use_localtime indicates whether or not to add the " (hh:mm -zzzz)" at the end. This also enables the atnight coloring.

This argument name was suggested in an earlier post and I guess I took it a little too literally...

Do you think it would be a good idea to take two separate options:
-atnight for the variable coloring, and -alt_time (or some other name) to show " (hh:mm -zzzz)" after the RFC 2822 string?

Or maybe take one option, named something like "-commitpage", to indicate that it is a format specific to that view? If it is not specified, the caller gets back an uncolored RFC 2822 date.

Also, is there a cleaner way of writing this?

sub timestamp_html {
    my %date = %{$_[0]};
    shift;
    my %opts = @_;

Or should I pass in the options as a hash reference, more like $cgi->a():

sub timestamp_html {
    my %date = %{$_[0]};
    my %opts = %{$_[1]};

Quoted 1 line

For the $feature{'localtime'} disabled case, the coloring is the same as before.

No, it is not the same.  It used to be

 Wed, 16 Mar 2011 07:02:42 +0000 (02:02 -0500)
                                  ^^^^^

and now it is

 Wed, 16 Mar 2011 07:02:42 +0000 (02:02 -0500) ^^^^^^^^^^^^^
which is I also think improvement,... but should be mentioned in the commit message.

Quoted 2 lines

I will paint the whole line in the next spin, and mention it in the commit message.

I think current solution of using

 Wed, 16 Mar 2011 02:02:42 -0500 (07:02:42 +0000)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

when 'localtime' feature is enabled is better than painting the whole:
you are now painting the _local_ part, i.e the part responsible for "atnight" warning.

Quoted 6 lines

Also, is there a cleaner way of writing this?

sub timestamp_html {
    my %date = %{$_[0]};
    shift;
    my %opts = @_;

 sub timestamp_html {
     my %date = %{ shift };
     my %opts = @_;

Or just use hash reference for $date:

 sub timestamp_html {
     my ($date, %opts) = @_;

and use $date->{'sth'}.

Quoted 3 lines · Jakub Narebski

 sub timestamp_html {
     my %date = %{ shift };
     my %opts = @_;

This did not work for me.  It interprets "shift" as a variable name.

This patch takes the same basic goal, display the appropriate times in a given timezone, and implements it in Javascript.  This requires adding / using a new class, dtcommit, which is based on the dtstart/dtend microformats.  Appropriate commit dates are wrapped in a span with this class, and a title of the time in ISO8601 format.

Quoted 5 lines · On Wed, Mar 23, 2011 at 5:08 PM, John 'Warthog9' Hawley…

This patch takes the same basic goal, display the appropriate times in a given timezone, and implements it in Javascript. This requires adding / using a new class, dtcommit, which is based on the dtstart/dtend microformats. Appropriate commit dates are wrapped in a span with this class, and a title of the time in ISO8601 format.

John,

Thanks for coding this up. I tested it on a couple of different browsers and wanted to share my observations with you.

First, the easy stuff:

1) "git am" complains about whitespace violations

2) HH:MM:SS times need zero padding; otherwise you see:

Tue, 8 Mar 2011 20:29:9 -0700

3) Some of the Javascript functions are double-indented, others single-indented.

4) IE6 does not seem to like ISO 8601 format:

x = new Date("2011-03-09T03:29:09Z");

This sets all fields to NaN. I suspect that getTime() values (milliseconds since 1970-01-01) are more portable.

I have attached a trivial patch for these four items; it applies on top of your original submission.

Some other things that popped up:

5) Some timezone offsets are not a whole number of hours. Bangalore time is GMT +0530, for instance.

6) Most U.S. timezones honor daylight savings, so they could be something like -0700 for part of the year, and -0800 for the rest of the year. Picking the "local" option would automatically adjust for this, but DST limits the usefulness of permanently storing a fixed TZ offset in the cookie.

7) Looking at a pre-DST commit after DST (or vice versa) can be a little confusing:

Tue, 8 Mar 2011 20:29:09 -0700 + (19:29 -0800)

I'm not sure which time to believe. (Although it's likely that a few weeks after a commit, the exact hour doesn't matter.)

8) The " + " popup menu is a little quirky. On FF 3.6 it partially collapses after selecting a value from the dropdown. On IE6 it shows "Error in parsing value for 'display'" and does not render. On Opera 11 it seemed to work OK.

Firefox breakage: http://img217.imageshack.us/f/firefoxa.png/

I'm wondering if there might be a better place on the page to put the TZ selection. It isn't immediately obvious to the user what the extra " + " does, and it seems to cause some issues.

If you decide to keep it where it is, you might want to consider absolute or fixed positioning so that other elements do not wrap around it. IOW it would work more like the dropdown menus on many sites.

The timezone fixup javascript seemed to work reasonably well, except for the hiccup with IE6. Maybe it would be worth splitting this into two patches: one to rewrite the timestamps, and a second one to add the TZ selection interface.

Quoted 8 lines · Kevin Cernekee

Quoted 5 lines · On Wed, Mar 23, 2011 at 5:08 PM, John 'Warthog9' Hawley…

This patch takes the same basic goal, display the appropriate times in a given timezone, and implements it in Javascript. This requires adding / using a new class, dtcommit, which is based on the dtstart/dtend microformats. Appropriate commit dates are wrapped in a span with this class, and a title of the time in ISO8601 format.

Quoted 6 lines

4) IE6 does not seem to like ISO 8601 format:

x = new Date("2011-03-09T03:29:09Z");

This sets all fields to NaN. I suspect that getTime() values (milliseconds since 1970-01-01) are more portable.

That's actually an issue, my understanding (as well as the understanding of all of the microformats that are out there) is that ISO 8601 is the "correct" format that these things should be in. If IE6 can't handle that (and I'll admit I don't have trivial access to older IEs for testing right now), then there is a *LOT* of Javascript out there that is just broken.

Going a bit further, I would draw the line in the sand for gitweb supporting IE as a browser somewhere around IE 7 or 8 at this point as well:

http://www.w3schools.com/browsers/browsers_explorer.asp

IE 5, 6 & 7 look to have negligible market share at best as it is, and I'm not sure it's worth trying to go back and support IE6 or anything prior.

Quoted 4 lines

Some other things that popped up:

5) Some timezone offsets are not a whole number of hours. Bangalore time is GMT +0530, for instance.

The code is capable of handling this, it's mainly an issue of interface, which I'll bring up in response to 6 & 7

Quoted 5 lines · On Wed, Mar 23, 2011 at 5:08 PM, John 'Warthog9' Hawley…

This patch takes the same basic goal, display the appropriate times in a given timezone, and implements it in Javascript.  This requires adding / using a new class, dtcommit, which is based on the dtstart/dtend microformats.  Appropriate commit dates are wrapped in a span with this class, and a title of the time in ISO8601 format.

John,

Thanks for coding this up. I tested it on a couple of different browsers and wanted to share my observations with you.

First, the easy stuff:

1) "git am" complains about whitespace violations

2) HH:MM:SS times need zero padding; otherwise you see:

Tue, 8 Mar 2011 20:29:9 -0700

4) IE6 does not seem to like ISO 8601 format:

x = new Date("2011-03-09T03:29:09Z");

This sets all fields to NaN. I suspect that getTime() values (milliseconds since 1970-01-01) are more portable.

I have attached a trivial patch for these four items; it applies on top of your original submission.

6) Most U.S. timezones honor daylight savings, so they could be something like -0700 for part of the year, and -0800 for the rest of the year. Picking the "local" option would automatically adjust for this, but DST limits the usefulness of permanently storing a fixed TZ offset in the cookie.

8) The " + " popup menu is a little quirky. On FF 3.6 it partially collapses after selecting a value from the dropdown. On IE6 it shows "Error in parsing value for 'display'" and does not render. On Opera 11 it seemed to work OK.

Firefox breakage: http://img217.imageshack.us/f/firefoxa.png/

I'm wondering if there might be a better place on the page to put the TZ selection. It isn't immediately obvious to the user what the extra " + " does, and it seems to cause some issues.

Quoted 9 lines · Kevin Cernekee

Quoted 5 lines · On Wed, Mar 23, 2011 at 5:08 PM, John 'Warthog9' Hawley…

This patch takes the same basic goal, display the appropriate times in a given timezone, and implements it in Javascript. This requires adding / using a new class, dtcommit, which is based on the dtstart/dtend microformats. Appropriate commit dates are wrapped in a span with this class, and a title of the time in ISO8601 format.

Quoted 4 lines

John,

Thanks for coding this up. I tested it on a couple of different browsers and wanted to share my observations with you.

I wonder if there is any site that allows to check JavaScript for compatibility with different browsers...

Quoted 3 lines

First, the easy stuff:

1) "git am" complains about whitespace violations

It would be more helpful if you wrote here what are those whitespace violations.

Quoted 1 line

Quoted 3 lines

2) HH:MM:SS times need zero padding; otherwise you see:

Tue, 8 Mar 2011 20:29:9 -0700

There is even padLeft function in gitweb.js ready to be (re)used...

[...]

Quoted 6 lines

4) IE6 does not seem to like ISO 8601 format:

x = new Date("2011-03-09T03:29:09Z");

This sets all fields to NaN. I suspect that getTime() values (milliseconds since 1970-01-01) are more portable.

Do you mean using epoch in title attribute, or fallback to parsing ISO 8601 UTC format with regexps?

Quoted 5 lines

6) Most U.S. timezones honor daylight savings, so they could be something like -0700 for part of the year, and -0800 for the rest of the year. Picking the "local" option would automatically adjust for this, but DST limits the usefulness of permanently storing a fixed TZ offset in the cookie.

Dealing with DST (zoneinfo library) is simply too hard for JavaScript IMHO. What we could do is to store "local" in cookie, not a fixed TZ offset (or perhaps store both as to not recalculate it).

Quoted 5 lines

8) The " + " popup menu is a little quirky. On FF 3.6 it partially collapses after selecting a value from the dropdown. On IE6 it shows "Error in parsing value for 'display'" and does not render. On Opera 11 it seemed to work OK.

Quoted 5 lines

Firefox breakage: http://img217.imageshack.us/f/firefoxa.png/

I'm wondering if there might be a better place on the page to put the TZ selection. It isn't immediately obvious to the user what the extra " + " does, and it seems to cause some issues.

Hmmm... perhaps a 'config' page?

Quoted 11 lines · Jakub Narebski

Quoted 6 lines · Kevin Cernekee

4) IE6 does not seem to like ISO 8601 format:

x = new Date("2011-03-09T03:29:09Z");

This sets all fields to NaN. I suspect that getTime() values (milliseconds since 1970-01-01) are more portable.

Do you mean using epoch in title attribute, or fallback to parsing ISO 8601 UTC format with regexps?

Parsing it with regexps is doable if completely inelegant, that said this is Javascript...

Looky that MS provides Virtual PC images for compat testing for IE6
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=21eabb90-958f-4b64-b5f1-73d0a413c8ef&displaylang=en

Ok reading through the documentation I can find for MS and their Date.parse (
http://msdn.microsoft.com/en-us/library/dctx55bc(v=VS7.1).aspx ) and some quick experimentation:

2011-03-09 - breaks
2011/03/09 - works

2011/03/09T01:01:01 - works, sorta - the hour comes out as 10 vs. 01 2011/03/09 01:01:01 - works, hour is correct
2011/03/09 01:01:01Z - works and seems to get the TZ correct 2011/03/09T01:01:01Z - breaks

Not really sure what the "right" way to fix this is going to end up being. Suppose our options are:

1) Try and find a format that is generally accepted and parseable on all the browsers
2) Declare IE6 an unsupported browser
3) Trap what browser we are on and do a regex parsing of the string and do appropriate sets or a more verbose format that works everywhere

4) Use a regex and sets for every browser.
5) Switch all the embedded times over to epochs in the title=""'s

4 is probably the "most" right that I can see of those options, and avoids possible other browser inconsistencies with respect to date parsing. I'm going to code that up (it shouldn't be terribly complicated), unless someone likes one of the other ideas better. Suppose we could even go down the more complicate microformat route and just write some code to parse that, just more complicated all the way around.

5 has the appeal that everything handles the epoch correctly, but it does have the downside of being less readable in the html code (and shifts us slightly further away from the accepted "standard" of the microcode formats)

Quoted 6 lines

4) IE6 does not seem to like ISO 8601 format:

x = new Date("2011-03-09T03:29:09Z");

This sets all fields to NaN.  I suspect that getTime() values (milliseconds since 1970-01-01) are more portable.

Do you mean using epoch in title attribute, or fallback to parsing ISO 8601 UTC format with regexps?

Dealing with DST (zoneinfo library) is simply too hard for JavaScript IMHO.  What we could do is to store "local" in cookie, not a fixed TZ offset (or perhaps store both as to not recalculate it).

Hmmm... perhaps a 'config' page?

2011/3/24 Jakub Narebski <[email protected]>:

Quoted 9 lines

Quoted 6 lines

4) IE6 does not seem to like ISO 8601 format:

x = new Date("2011-03-09T03:29:09Z");

This sets all fields to NaN. I suspect that getTime() values (milliseconds since 1970-01-01) are more portable.

Do you mean using epoch in title attribute, or fallback to parsing ISO 8601 UTC format with regexps?

getTime() format is $epoch * 1000. When I switched to that format, all 3 of my browsers were able to handle it.

I really don't think relying on "new Date(iso8601_timestamp)" is a good idea, but I guess the string parsing approach would work:

http://webcloud.se/log/JavaScript-and-ISO-8601/

Quoted 3 lines

Dealing with DST (zoneinfo library) is simply too hard for JavaScript IMHO. What we could do is to store "local" in cookie, not a fixed TZ offset (or perhaps store both as to not recalculate it).

I agree, and I do not have a comprehensive solution for handling non-local timezones.

Quoted 1 line

Hmmm... perhaps a 'config' page?

Any thoughts on what other user-configurable items might get added in the future, and whether they will be on the client side or server side?

This patch is based on Kevin Cernekee's <[email protected]> patch series entitled "gitweb: introduce localtime feature". While Kevin's patch changed the server side output so that the timezone was output from gitweb itself, this has a number of drawbacks, in particular with respect to gitweb-caching.

This patch takes the same basic goal, display the appropriate times in a given timezone, and implements it in Javascript. This requires adding / using a new class, dtcommit, which is based on the dtstart/dtend microformats. Appropriate commit dates are wrapped in a span with this class, and a title of the time in ISO8601 format.

Enabling this will then add several javascript files to be loaded,

a default timezone to be selected and a single onloadTZSetup() function to be called.

This will place a "+" to the right of an appropriate time and clicking on it will give you a drop down to choose the timezone to change to.

All changes are saved to a Javascript cookie, so page changes and browser closure / reopening retains the last known setting used.

Fallback (should Javascript not be enabled) is to treat dates as they have been and display them, only, in UTC.

Valid timezones, currently, are:

utc
local
-1200
-1100
...
+1100
+1200

With each timezone being +1hr to the previous. The code is capable of handling fractional timezones, but those have not been added.

Pages Affected:
* 'summary' view, "last change" field (commit time from latest change)
* 'log' view, author time
* 'commit' and 'commitdiff' views, author/committer time

Based-on-code-from: Kevin Cernekee <[email protected]>

Signed-off-by John 'Warthog9' Hawley <[email protected]>

---
 gitweb/gitweb.perl              |   64 +++++++++++++++-
 gitweb/static/js/common-defs.js |   12 +++
 gitweb/static/js/common-lib.js  |   32 ++++++++
 gitweb/static/js/cookies.js     |   35 +++++++++
 gitweb/static/js/date.js        |  160 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 300 insertions(+), 3 deletions(-)
 create mode 100644 gitweb/static/js/common-defs.js
 create mode 100644 gitweb/static/js/common-lib.js
 create mode 100644 gitweb/static/js/cookies.js
 create mode 100644 gitweb/static/js/date.js

gitweb/gitweb.perl +0 -0

index 9dccfb0..2a662d8 100755
@@ -261,6 +261,49 @@ our %highlight_ext = (
 	map { $_ => 'xml' } qw(xhtml html htm),

gitweb/gitweb.perl +15 -0

+#	-1200
+#	-1100
+#	-1000
+#	-0900
+#	-0800
+#	-0700
+#	-0600
+#	-0500
+#	-0400
+#	-0300
+#	-0200
+#	-0100
+#	+0000
+#	+0100
+#	+0200

gitweb/gitweb.perl +1 -1

-	      " [$ad{'rfc2822'}";
+	      " [<span class=\"dtcommit\" title=\"$ad{'iso-8601'}\">$ad{'rfc2822'}</span>";

gitweb/gitweb.perl +1 -1

-		      "<td></td><td> $wd{'rfc2822'}";
+		      "<td></td><td> <span class=\"dtcommit\" title=\"$wd{'iso-8601'}\">$wd{'rfc2822'}</span>";

gitweb/static/js/common-defs.js new file +2 -0

new file mode 100644
index 0000000..23a1cc2
@@ -0,0 +1,12 @@
+// Copyright (C) 2011, John 'Warthog9' Hawley <[email protected]>
+//

gitweb/static/js/common-lib.js new file +22 -0

new file mode 100644
index 0000000..2ce65ec
@@ -0,0 +1,32 @@
+// Copyright (C) 2011, John 'Warthog9' Hawley <[email protected]>
+//
+//
+// JavaScript date handling code for gitweb (git web interface).
+// @license GPLv2 or later
+//
+//
+function findElementsByClassName( className ) {
+	if( document.getElementsByClassName == undefined) {
+		var hasClassName = new RegExp("(?:^|\\s)" + className + "(?:$|\\s)");
+		var allElements = document.getElementsByTagName("*");
+		var foundElements = [];
+
+		var element = null;
+		for (var x = 0; (element = allElements[x]) != null; x++) {
+			var curClass = element.className;
+			if(
+				curClass				// If we've actually got something
+				&&
+				curClass.indexOf(className) != -1	// And it has a valid index, I.E. not -1
+				&&
+				hasClassName.test(curClass)		// and the regex passes

gitweb/static/js/cookies.js new file +1 -0

new file mode 100644
index 0000000..8c8f7aa
@@ -0,0 +1,35 @@
+// Copyright (C) 2011, John 'Warthog9' Hawley <[email protected]>

gitweb/static/js/date.js new file +2 -0

new file mode 100644
index 0000000..a6d6f81
@@ -0,0 +1,160 @@
+// Copyright (C) 2011, John 'Warthog9' Hawley <[email protected]>
+//

gitweb/static/js/date.js new file +6 -0

+		var offsetArr = 14;
+		arrSelected[0] = " ";
+		arrSelected[1] = " ";
+		if( preSetTZ == "utc" ) {
+			arrSelected[0] = " selected=\"selected\" ";
+		} else if( preSetTZ == "local" ){

+<table border=\"1\">\

gitweb/static/js/date.js new file +14 -0

+	<tr>\
+		<td>\
+			Time Zone:\
+		</td>\
+		<td>\
+			<select name=\"tzoffset\" onchange=\"tzChange(this.value);\">\
+				<option "+ arrSelected[0] +" value=\"utc\">UTC/GMT</option>\
+				<option "+ arrSelected[1] +" value=\"local\">Local (per browser)</option>";
+		for( x = -12; x <= 12; x++){
+			var tzOffset = formatTZ( x );
+			txtTzSelect +="					<option "+ arrSelected[x + offsetArr] +"value=\""+ tzOffset +"\">"+ tzOffset +"</option>";
+		}
+		txtTzSelect += "\
+			</select>\

Quoted 2 lines · On Thu, 24 Mar 2011, John 'Warthog9' Hawley wrote:

With each timezone being +1hr to the previous. The code is capable of handling fractional timezones, but those have not been added.

NOTE: I think that current gitweb code (parse_date / format_date) doesn't handle negative fractional timezones correctly.

        $tz =~ m/^([+\-][0-9][0-9])([0-9][0-9])$/;
        my $local = $epoch + ((int $1 + ($2/60)) * 3600);

Though git.git repository doesn't contain negative fractional timezones... it does contain positive fractional timezones however.

  $ git log --pretty='%ai%n%ci' --all | cut -d' ' -f 3 | sort -n | uniq

Could anyone check it e.g. on Linux kernel repository?

2011/3/25 Jakub Narebski <[email protected]>:

Review sub parse_date { · line 2925

Quoted 8 lines

(quoted diff) +2 -2

@@ -2921,8 +2921,10 @@ sub parse_date {
        $date{'iso-8601'}  = sprintf "%04d-%02d-%02dT%02d:%02d:%02dZ",
                             1900+$year, 1+$mon, $mday, $hour ,$min, $sec;
 
-       $tz =~ m/^([+\-][0-9][0-9])([0-9][0-9])$/;
-       my $local = $epoch + ((int $1 + ($2/60)) * 3600);
+       my ($tz_sign, $tz_hour, $tz_min) =
+               ($tz =~ m/^([+\-])([0-9][0-9])([0-9][0-9])$/);

It's just a matter of personal preference, but I would find this regexp slightly easier to read:

+ ($tz =~ m/^([+\-])([0-9]{2})([0-9]{2})$/);

Review sub parse_date { · line 2927

Quoted 2 lines

(quoted diff) +2 -0

+       $tz_sign = ($tz_sign eq '-' ? -1 : +1);
+       my $local = $epoch + $tz_sign*($tz_hour + ($tz_min/60.0))*3600;

If you wanted to avoid floats, you could do something like:

+ my $local = $epoch + $tz_sign * ($tz_hour * 3600 + $tz_min * 60);

It's just a matter of personal preference, but I would find this regexp slightly easier to read:

+ ($tz =~ m/^([+\-])([0-9]{2})([0-9]{2})$/);

Quoted 2 lines

+       $tz_sign = ($tz_sign eq '-' ? -1 : +1);
+       my $local = $epoch + $tz_sign*($tz_hour + ($tz_min/60.0))*3600;

If you wanted to avoid floats, you could do something like:

+ my $local = $epoch + $tz_sign * ($tz_hour * 3600 + $tz_min * 60);

Quoted 4 lines · Kevin Cernekee

It's just a matter of personal preference, but I would find this regexp slightly easier to read:

+ ($tz =~ m/^([+\-])([0-9]{2})([0-9]{2})$/);

I'd say "^([-+])(\d\d)(\d\d)$" makes it the most clear.

Care to re-roll the patch?

Quoted 4 lines · Kevin Cernekee

It's just a matter of personal preference, but I would find this regexp slightly easier to read:

+ ($tz =~ m/^([+\-])([0-9]{2})([0-9]{2})$/);

I'd say "^([-+])(\d\d)(\d\d)$" makes it the most clear.

Quoted 6 lines

Review

Quoted 2 lines

(quoted diff) +2 -0

+       $tz_sign = ($tz_sign eq '-' ? -1 : +1);
+       my $local = $epoch + $tz_sign*($tz_hour + ($tz_min/60.0))*3600;

If you wanted to avoid floats, you could do something like:

+ my $local = $epoch + $tz_sign * ($tz_hour * 3600 + $tz_min * 60);

That is not just float-avoidance, but is much more logical.

	(($h * 60) + $m) * 60

may be even more logical and more readable, though.

Care to re-roll the patch?

One might reasonably expect a function named parse_date() to be used for something along these lines:

$unix_time_t = parse_date("2011-03-19");

But instead, gitweb's parse_date works more like:

&parse_date(1300505805) = {

        'hour' => 3,
        'minute' => 36,
        ...
        'rfc2822' => 'Sat, 19 Mar 2011 03:36:45 +0000',
        ...
}

Rename the function [to format_date] to improve clarity. No change to functionality.

Signed-off-by Kevin Cernekee <[email protected]>

---
 gitweb/gitweb.perl |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

On Sat, 19 Mar 2011, Kevin Cernekee wrote:

 - formatted_date
 - process_date, process_raw_date, process_git_date
 - process_epoch, process_timestamp
 - date_formats
 - from_epoch, date_from_epoch

One might reasonably expect a function named parse_date() to be used for something along these lines:

$unix_time_t = parse_date("2011-03-19");

But instead, gitweb's parse_date works more like:

&parse_date(1300505805) = {
        'hour' => 3,
        'minute' => 36,
        ...
        'rfc2822' => 'Sat, 19 Mar 2011 03:36:45 +0000',
        ...
}

Rename the function to improve clarity. No change to functionality.