Граф коммитов

74 Коммитов

Автор SHA1 Сообщение Дата
Mike Gorchak e1033da6af Fix time offset calculation in case of unsigned time_t
Fix time offset calculation expression in case if time_t
is unsigned. This code works fine for signed and
unsigned time_t.

Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-25 14:29:12 -08:00
Mike Gorchak e6e87516f5 date.c: fix unsigned time_t comparison
tm_to_time_t() returns (time_t)-1 when it sees an error.  On
platforms with unsigned time_t, this value will be larger than any
valid timestamp and will break the "Is this older than 10 days in
the future?" check.

Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-25 14:23:43 -08:00
Junio C Hamano 9a0231b395 Merge branch 'jc/maint-filter-branch-epoch-date'
In 1.7.9 era, we taught "git rebase" about the raw timestamp format
but we did not teach the same trick to "filter-branch", which rolled
a similar logic on its own.  Because of this, "filter-branch" failed
to rewrite commits with ancient timestamps.

* jc/maint-filter-branch-epoch-date:
  t7003: add test to filter a branch with a commit at epoch
  date.c: Fix off by one error in object-header date parsing
  filter-branch: do not forget the '@' prefix to force git-timestamp
2012-07-22 12:55:05 -07:00
Junio C Hamano be21d167b2 date.c: Fix off by one error in object-header date parsing
It is perfectly OK for a valid decimal integer to begin with '9' but
116eb3a (parse_date(): allow ancient git-timestamp, 2012-02-02) did
not express the range correctly.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-12 13:49:41 -07:00
Jonathan Nieder 7d29afd43c i18n: mark relative dates for translation
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24 14:55:48 -07:00
Junio C Hamano 3d8bc74127 Merge branch 'jc/parse-date-raw'
* jc/parse-date-raw:
  parse_date(): '@' prefix forces git-timestamp
  parse_date(): allow ancient git-timestamp
2012-02-10 14:08:12 -08:00
Junio C Hamano 2c733fb24c parse_date(): '@' prefix forces git-timestamp
The only place that the issue this series addresses was observed
where we read "cat-file commit" output and put it in GIT_AUTHOR_DATE
in order to replay a commit with an ancient timestamp.

With the previous patch alone, "git commit --date='20100917 +0900'"
can be misinterpreted to mean an ancient timestamp, not September in
year 2010.  Guard this codepath by requring an extra '@' in front of
the raw git timestamp on the parsing side. This of course needs to
be compensated by updating get_author_ident_from_commit and the code
for "git commit --amend" to prepend '@' to the string read from the
existing commit in the GIT_AUTHOR_DATE environment variable.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-03 23:11:32 -08:00
Junio C Hamano 116eb3abfe parse_date(): allow ancient git-timestamp
The date-time parser parses out a human-readble datestring piece by
piece, so that it could even parse a string in a rather strange
notation like 'noon november 11, 2005', but restricts itself from
parsing strings in "<seconds since epoch> <timezone>" format only
for reasonably new timestamps (like 1974 or newer) with 10 or more
digits. This is to prevent a string like "20100917" from getting
interpreted as seconds since epoch (we want to treat it as September
17, 2010 instead) while doing so.

The same codepath is used to read back the timestamp that we have
already recorded in the headers of commit and tag objects; because
of this, such a commit with timestamp "0 +0000" cannot be rebased or
amended very easily.

Teach parse_date() codepath to special case a string of the form
"<digits> +<4-digits>" to work this issue around, but require that
there is no other cruft around the string when parsing a timestamp
of this format for safety.

Note that this has a slight backward incompatibility implications.

If somebody writes "git commit --date='20100917 +0900'" and wants it
to mean a timestamp in September 2010 in Japan, this change will
break such a use case.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-03 23:11:32 -08:00
Haitao Li ee646eb48f date.c: Support iso8601 timezone formats
Timezone designators in the following formats are all valid according to
ISO8601:2004, section 4.3.2:

    [+-]hh, [+-]hhmm, [+-]hh:mm

but we have ignored the ones with colon so far.

Signed-off-by: Haitao Li <lihaitao@gmail.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-12 16:49:14 -07:00
Michael J Gruber f1e9c548ce date: avoid "X years, 12 months" in relative dates
When relative dates are more than about a year ago, we start
writing them as "Y years, M months".  At the point where we
calculate Y and M, we have the time delta specified as a
number of days. We calculate these integers as:

  Y = days / 365
  M = (days % 365 + 15) / 30

This rounds days in the latter half of a month up to the
nearest month, so that day 16 is "1 month" (or day 381 is "1
year, 1 month").

We don't round the year at all, though, meaning we can end
up with "1 year, 12 months", which is silly; it should just
be "2 years".

Implement this differently with months of size

  onemonth = 365/12

so that

  totalmonths = (long)( (days + onemonth/2)/onemonth )
  years = totalmonths / 12
  months = totalmonths % 12

In order to do this without floats, we write the first formula as

  totalmonths = (days*12*2 + 365) / (365*2)

Tests and inspiration by Jeff King.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-20 19:23:16 -07:00
Jonathan Nieder 9644c06163 Export parse_date_basic() to convert a date string to timestamp
approxidate() is not appropriate for reading machine-written dates
because it guesses instead of erroring out on malformed dates.
parse_date() is less convenient since it returns its output as a
string.  So export the underlying function that writes a timestamp.

While at it, change the return value to match the usual convention:
return 0 for success and -1 for failure.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-15 15:35:12 -07:00
Jeff King 9ba0f0334d parse_date: fix signedness in timezone calculation
When no timezone is specified, we deduce the offset by
subtracting the result of mktime from our calculated
timestamp.

However, our timestamp is stored as an unsigned integer,
meaning we perform the subtraction as unsigned. For a
negative offset, this means we wrap to a very high number,
and our numeric timezone is in the millions of hours. You
can see this bug by doing:

   $ TZ=EST \
     GIT_AUTHOR_DATE='2010-06-01 10:00' \
     git commit -a -m foo
   $ git cat-file -p HEAD | grep author
   author Jeff King <peff@peff.net> 1275404416 +119304128

Instead, we should perform this subtraction as a time_t, the
same type that mktime returns.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05 11:57:07 -07:00
Junio C Hamano 8718e87508 Merge branch 'rr/parse-date-refactor'
* rr/parse-date-refactor:
  Refactor parse_date for approxidate functions
2010-06-21 06:02:47 -07:00
Ramkumar Ramachandra c5043cc185 Refactor parse_date for approxidate functions
approxidate_relative and approxidate_careful both use parse_date to
dump the timestamp to a character buffer and parse it back into a long
unsigned using strtoul(). Avoid doing this by creating a new
parse_date_toffset method.

Noticed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-07 15:52:43 -07:00
Marcus Comstedt 75b37e7047 Add "Z" as an alias for the timezone "UTC"
The name "Z" for the UTC timezone is required to properly parse ISO 8601
timestamps.  Add it to the list of recognized timezones.

Because timezone names can be shorter than 3 letters, loosen the
restriction in match_alpha() that used to require at least 3 letters to
match to allow a short timezone name as long as it matches exactly.  Prior
to the introduction of the "Z" zone, this already affected the timezone
"NT" (Nome).

Signed-off-by: Marcus Comstedt <marcus@mc.pp.se>
Reviewed-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-18 22:00:17 -07:00
Junio C Hamano 103209c678 Merge branch 'jc/maint-reflog-bad-timestamp'
* jc/maint-reflog-bad-timestamp:
  t0101: use a fixed timestamp when searching in the reflog
  Update @{bogus.timestamp} fix not to die()
  approxidate_careful() reports errorneous date string
2010-01-27 14:57:37 -08:00
Junio C Hamano 93cfa7c7a8 approxidate_careful() reports errorneous date string
For a long time, the time based reflog syntax (e.g. master@{yesterday})
didn't complain when the "human readable" timestamp was misspelled, as
the underlying mechanism tried to be as lenient as possible.  The funny
thing was that parsing of "@{now}" even relied on the fact that anything
not recognized by the machinery returned the current timestamp.

Introduce approxidate_careful() that takes an optional pointer to an
integer, that gets assigned 1 when the input does not make sense as a
timestamp.

As I am too lazy to fix all the callers that use approxidate(), most of
the callers do not take advantage of the error checking, but convert the
code to parse reflog to use it as a demonstration.

Tests are mostly from Jeff King.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-26 13:51:41 -08:00
Junio C Hamano 23418ea95f date.c: mark file-local function static
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20 14:37:17 -08:00
Johan Sageryd dbc1b1f710 Fix '--relative-date'
This fixes '--relative-date' so that it does not give '0
year, 12 months', for the interval 360 <= diff < 365.

Signed-off-by: Johan Sageryd <j416@1616.se>
Signed-off-by: Jeff King <peff@peff.net>
2009-10-03 06:04:38 -04:00
Jeff King 931e8e27d9 fix approxidate parsing of relative months and years
These were broken by b5373e9. The problem is that the code
marks the month and year with "-1" for "we don't know it
yet", but the month and year code paths were not adjusted to
fill in the current time before doing their calculations
(whereas other units follow a different code path and are
fine).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-30 22:04:56 -07:00
Alex Riesen 33012fc429 Add date formatting and parsing functions relative to a given time
The main purpose is to allow predictable testing of the code.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-30 19:59:11 -07:00
Linus Torvalds 36e4986f26 Further 'approxidate' improvements
The previous patch to improve approxidate got us to the point that a lot
of the remaining annoyances were due to the 'strict' date handling running
first, and deciding that it got a good enough date that the approximate
date routines were never even invoked.

For example, using a date string like

	6AM, June 7, 2009

the strict date logic would be perfectly happy with the "June 7, 2009"
part, and ignore the 6AM part that it didn't understand - resulting in the
information getting dropped on the floor:

	6AM, June 7, 2009 -> Sat Jun 6 00:00:00 2009

and the date being calculated as if it was midnight, and the '6AM' having
confused the date routines into thinking about '6 June' rather than 'June
7' at 6AM (ie notice how the _day_ was wrong due to this, not just the
time).

So this makes the strict date routines a bit stricter, and requires that
not just the date, but also the time, has actually been parsed. With that
fix, and trivial extension of the approxidate routines, git now properly
parses the date as

	6AM, June 7, 2009 -> Sun Jun  7 06:00:00 2009

without dropping the fuzzy time ("6AM" or "noon" or any of the other
non-strict time formats) on the floor.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-22 18:51:06 -07:00
Linus Torvalds 9029055207 Improve on 'approxidate'
This is not a new failure mode - approxidate has always been kind of
random in the input it accepts, but some of the randomness is more
irritating than others.

For example:

	Jun 6, 5AM -> Mon Jun 22 05:00:00 2009
	5AM Jun 6 -> Sat Jun  6 05:00:00 2009

Whaa? The reason for the above is that approxidate squirrells away the '6'
from "Jun 6" to see if it's going to be a relative number, and then
forgets about it when it sees a new number (the '5' in '5AM'). So the odd
"June 22" date is because today is July 22nd, and if it doesn't have
another day of the month, it will just pick todays mday - having ignored
the '6' entirely due to getting all excited about seeing a new number (5).

There are other oddnesses. This does not fix them all, but I think it
makes for fewer _really_ perplexing cases. At least now we have

	Jun 6, 5AM -> Sat Jun  6 05:00:00 2009
	5AM, Jun 6 -> Sat Jun  6 05:00:00 2009

which makes me happier. I can still point to cases that don't work as
well, but those are separate issues.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-22 18:51:05 -07:00
Bernd Ahlers f697b33b01 Work around BSD whose typeof(tv.tv_sec) != time_t
According to POSIX, tv_sec is supposed to be a time_t, but OpenBSD
(and FreeBSD, too) defines it to be a long, which triggers a type
mismatch when a pointer to it is given to localtime_r().

Acked-by: Jeff King <peff@peff.net>

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-05 22:19:14 -07:00
Jeff King 10edf37796 never fallback relative times to absolute
Previously, for dates older than 12 months we fell back to just giving the
absolute time.  This can be a bit jarring when reading a list of times.

Instead, let's switch to "Y years, M months" for five years, and then just
"Y years" after that.

No particular reason on the 5 year cutoff except that it seemed reasonable
to me.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-25 00:44:43 -08:00
Linus Torvalds 7dff9b30ea Support 'raw' date format
Talking about --date, one thing I wanted for the 1234567890 date was to
get things in the raw format. Sure, you get them with --pretty=raw, but it
felt a bit sad that you couldn't just ask for the date in raw format.

So here's a throw-away patch (meaning: I won't be re-sending it, because I
really don't think it's a big deal) to add "--date=raw". It just prints
out the internal raw git format - seconds since epoch plus timezone (put
another way: 'date +"%s %z"' format)

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-20 21:45:42 -08:00
Linus Torvalds 9f2b6d2936 date/time: do not get confused by fractional seconds
The date/time parsing code was confused if the input time HH:MM:SS is
followed by fractional seconds.  Since we do not record anything finer
grained than seconds, we could just drop fractional part, but there is a
twist.

We have taught people that not just spaces but dot can be used as word
separators when spelling things like:

    $ git log --since 2.days
    $ git show @{12:34:56.7.days.ago}

and we shouldn't mistake "7" in the latter example as a fraction and
discard it.

The rules are:

 - valid days of month/mday are always single or double digits.

 - valid years are either two or four digits

   No, we don't support the year 600 _anyway_, since our encoding is based
   on the UNIX epoch, and the day we worry about the year 10,000 is far
   away and we can raise the limit to five digits when we get closer.

 - Other numbers (eg "600 days ago") can have any number of digits, but
   they cannot start with a zero. Again, the only exception is for
   two-digit numbers, since that is fairly common for dates ("Dec 01" is
   not unheard of)

So that means that any milli- or micro-second would be thrown out just
because the number of digits shows that it cannot be an interesting date.

A milli- or micro-second can obviously be a perfectly fine number
according to the rules above, as long as it doesn't start with a '0'. So
if we have

	12:34:56.123

then that '123' gets parsed as a number, and we remember it. But because
it's bigger than 31, we'll never use it as such _unless_ there is
something after it to trigger that use.

So you can say "12:34:56.123.days.ago", and because of the "days", that
123 will actually be meaninful now.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-17 17:41:53 -07:00
Johannes Sixt bb5799d6ef Make my_mktime() public and rename it to tm_to_time_t()
We will use it from the MinGW port's gettimeofday() substitution.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
2008-06-23 13:40:29 +02:00
Olivier Marin 8c6b57860d Fix approxidate("never") to always return 0
Commit af66366a9f introduced the keyword
"never" to be used with approxidate() but defined it with a fixed date
without taking care of timezone. As a result approxidate() will return
a timestamp in the future with a negative timezone.

With this patch, approxidate("never") always return 0 whatever your
timezone is.

Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-17 16:40:09 -07:00
Steven Drake 695ed47228 timezone_names[]: fixed the tz offset for New Zealand.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-25 21:56:10 -08:00
Andy Parkins 856665f827 parse_date_format(): convert a format name to an enum date_mode
Factor out the code to parse --date=<format> parameter to revision
walkers into a separate function, parse_date_format().  This function
is passed a string and converts it to an enum date_format:

 - "relative"         => DATE_RELATIVE
 - "iso8601" or "iso" => DATE_ISO8601
 - "rfc2822"          => DATE_RFC2822
 - "short"            => DATE_SHORT
 - "local"            => DATE_LOCAL
 - "default"          => DATE_NORMAL

In the event that none of these strings is found, the function die()s.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-29 20:31:59 -07:00
Johannes Schindelin af66366a9f Teach approxidate() to understand "never"
If you want to keep the reflogs around for a really long time, you should be
able to say so:

	$ git config gc.reflogExpire never

Now it works, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-24 17:28:10 -07:00
Junio C Hamano 73013afd14 Make show_rfc2822_date() just another date output format.
These days, show_date() takes a date_mode parameter to specify
the output format, and a separate specialized function for dates
in E-mails does not make much sense anymore.

This retires show_rfc2822_date() function and make it just
another date output format.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-13 23:14:52 -07:00
Robin Rosenberg ee8f838e03 Support output ISO 8601 format dates
Support output of full ISO 8601 style dates in e.g. git log
and other places that use interpolation for formatting.

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-13 22:47:49 -07:00
Junio C Hamano a6080a0a44 War on whitespace
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time.  There are a few files that need
to have trailing whitespaces (most notably, test vectors).  The results
still passes the test, and build result in Documentation/ area is unchanged.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07 00:04:01 -07:00
Johannes Sixt a1a5a6347b Accept dates before 2000/01/01 when specified as seconds since the epoch
Tests with git-filter-branch on a repository that was converted from
CVS and that has commits reaching back to 1999 revealed that it is
necessary to parse dates before 2000/01/01 when they are specified
as seconds since 1970/01/01. There is now still a limit, 100000000,
which is 1973/03/03 09:46:40 UTC, in order to allow that dates are
represented as 8 digits.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06 15:20:12 -07:00
Junio C Hamano a7b02ccf9a Add --date={local,relative,default}
This adds --date={local,relative,default} option to log family of commands,
to allow displaying timestamps in user's local timezone, relative time, or
the default format.

Existing --relative-date option is a synonym of --date=relative; we could
probably deprecate it in the long run.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-25 21:39:43 -07:00
Johannes Schindelin f8493ec09b show_date(): rename the "relative" parameter to "mode"
Now, show_date() can print three different kinds of dates: normal,
relative and short (%Y-%m-%s) dates.

To achieve this, the "int relative" was changed to "enum date_mode
mode", which has three states: DATE_NORMAL, DATE_RELATIVE and
DATE_SHORT.

Since existing users of show_date() only call it with relative_date
being either 0 or 1, and DATE_NORMAL and DATE_RELATIVE having these
values, no behaviour is changed.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-27 17:29:37 -08:00
Johannes Schindelin da8f070cee show_date(): fix relative dates
We pass a timestamp (i.e. number of seconds elapsed since Jan 1 1970,
00:00:00 GMT) to the function. So there is no need to "fix" the
timestamp according to the timezone.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2007-01-20 18:57:47 -08:00
Junio C Hamano 85023577a8 simplify inclusion of system header files.
This is a mechanical clean-up of the way *.c files include
system header files.

 (1) sources under compat/, platform sha-1 implementations, and
     xdelta code are exempt from the following rules;

 (2) the first #include must be "git-compat-util.h" or one of
     our own header file that includes it first (e.g. config.h,
     builtin.h, pkt-line.h);

 (3) system headers that are included in "git-compat-util.h"
     need not be included in individual C source files.

 (4) "git-compat-util.h" does not have to include subsystem
     specific header files (e.g. expat.h).

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20 09:51:35 -08:00
Linus Torvalds 18b633cafc Fix approxidate() to understand 12:34 AM/PM are 00:34 and 12:34
It just simplifies the whole thing to say

	"hour = (hour % 12) + X"

where X is 12 for PM and 0 for AM.

It also fixes the "exact date" parsing, which didn't parse AM at all, and
as such would do the same "12:30 AM" means "12:30 24-hour-format" bug. Of
course, I hope that no exact dates use AM/PM anyway, but since we support
the PM format, let's just get it right.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-29 13:04:09 -07:00
Linus Torvalds 393d340e4f Fix approxidate() to understand more extended numbers
You can now say "5:35 PM yesterday", and approxidate() gets the right answer.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-28 18:25:25 -07:00
Linus Torvalds e92a54d99c Clean up approxidate() in preparation for fixes
Our approxidate cannot handle simple times like "5 PM yesterday", and to
fix that, we will need to add some logic for number handling.  This just
splits that out into a function of its own (the same way the _real_ date
parsing works).

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-28 18:23:25 -07:00
Linus Torvalds 9a8e35e987 Relative timestamps in git log
I noticed that I was looking at the kernel gitweb output at some point
rather than just do "git log", simply because I liked seeing the
simplified date-format, ie the "5 days ago" rather than a full date.

This adds infrastructure to do that for "git log" too. It does NOT add the
actual flag to enable it, though, so right now this patch is a no-op, but
it should now be easy to add a command line flag (and possibly a config
file option) to just turn on the "relative" date format.

The exact cut-off points when it switches from days to weeks etc are
totally arbitrary, but are picked somewhat to avoid the "1 weeks ago"
thing (by making it show "10 days ago" rather than "1 week", or "70
minutes ago" rather than "1 hour ago").

[jc: with minor fix and tweak around "month" and "week" area.]

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-26 19:12:03 -07:00
Pierre Habouzit 5df7dbbae4 n is in fact unused, and is later shadowed.
date.c::approxidate_alpha() counts the number of alphabets
while moving the pointer but does not use the count.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23 18:47:39 -07:00
Paul Eggert 7122f82f56 date.c: improve guess between timezone offset and year.
When match_digit() guesses a four-digit string to tell if it is
a year or a timezone, it did not consider that some real-world
places have UTC offsets equal to +1400.

   $ date; TZ=UTC0 date; TZ=Pacific/Kiritimati date
   Wed Jun  7 23:25:42 PDT 2006
   Thu Jun  8 06:25:42 UTC 2006
   Thu Jun  8 20:25:42 LINT 2006

Signed-off-by: Paul Eggert <eggert@CS.UCLA.EDU>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-08 21:22:33 -07:00
Junio C Hamano 2a38704323 Use RFC2822 dates from "git fmt-patch".
Still Work-in-progress git fmt-patch (should it be known as
format-patch-ng?) is matched with the fix made by Huw Davies
in 262a6ef76a commit to use
RFC2822 date format.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-01 01:44:33 -07:00
Junio C Hamano 38035cf4a5 date parsing: be friendlier to our European friends.
This does three things, only applies to cases where the user
manually tries to override the author/commit time by environment
variables, with non-ISO, non-2822 format date-string:

 - Refuses to use the interpretation to put the date in the
   future; recent kernel history has a commit made with
   10/03/2006 which is recorded as October 3rd.

 - Adds '.' as the possible year-month-date separator.  We
   learned from our European friends on the #git channel that
   dd.mm.yyyy is the norm there.

 - When the separator is '.', we prefer dd.mm.yyyy over
   mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
   dd/mm/yy[yy].

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-05 15:47:17 -07:00
Junio C Hamano 12d81ce598 Merge branch 'fix'
* fix:
  diff_flush(): leakfix.
  parse_date(): fix parsing 03/10/2006
2006-04-05 02:50:54 -07:00
Junio C Hamano fa0cdab537 parse_date(): fix parsing 03/10/2006
The comment associated with the date parsing code for three
numbers separated with slashes or dashes implied we wanted to
interpret using this order:

	yyyy-mm-dd
	yyyy-dd-mm
	mm-dd-yy
	dd-mm-yy

However, the actual code had the last two wrong, and making it
prefer dd-mm-yy format over mm-dd-yy.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-04 23:00:18 -07:00