aboutsummaryrefslogtreecommitdiff
path: root/date.c
Commit message (Collapse)AuthorAge
* i18n: mark relative dates for translationJonathan Nieder2012-04-24
| | | | | | 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>
* Merge branch 'jc/parse-date-raw'Junio C Hamano2012-02-10
|\ | | | | | | | | | | * jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
| * parse_date(): '@' prefix forces git-timestampJunio C Hamano2012-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * parse_date(): allow ancient git-timestampJunio C Hamano2012-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | date.c: Support iso8601 timezone formatsHaitao Li2011-09-12
|/ | | | | | | | | | | | | 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>
* date: avoid "X years, 12 months" in relative datesMichael J Gruber2011-04-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Export parse_date_basic() to convert a date string to timestampJonathan Nieder2010-07-15
| | | | | | | | | | | | | | | 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>
* parse_date: fix signedness in timezone calculationJeff King2010-07-05
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'rr/parse-date-refactor'Junio C Hamano2010-06-21
|\ | | | | | | | | * rr/parse-date-refactor: Refactor parse_date for approxidate functions
| * Refactor parse_date for approxidate functionsRamkumar Ramachandra2010-06-07
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Add "Z" as an alias for the timezone "UTC"Marcus Comstedt2010-05-18
|/ | | | | | | | | | | | | | | 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>
* Merge branch 'jc/maint-reflog-bad-timestamp'Junio C Hamano2010-01-27
|\ | | | | | | | | | | | | * 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
| * approxidate_careful() reports errorneous date stringJunio C Hamano2010-01-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | date.c: mark file-local function staticJunio C Hamano2010-01-20
|/ | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Fix '--relative-date'Johan Sageryd2009-10-03
| | | | | | | | 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>
* fix approxidate parsing of relative months and yearsJeff King2009-08-30
| | | | | | | | | | | | 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>
* Add date formatting and parsing functions relative to a given timeAlex Riesen2009-08-30
| | | | | | | | 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>
* Further 'approxidate' improvementsLinus Torvalds2009-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Improve on 'approxidate'Linus Torvalds2009-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Work around BSD whose typeof(tv.tv_sec) != time_tBernd Ahlers2009-05-05
| | | | | | | | | | 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>
* never fallback relative times to absoluteJeff King2009-02-25
| | | | | | | | | | | | | | 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>
* Support 'raw' date formatLinus Torvalds2009-02-20
| | | | | | | | | | | | | | 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>
* date/time: do not get confused by fractional secondsLinus Torvalds2008-08-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make my_mktime() public and rename it to tm_to_time_t()Johannes Sixt2008-06-23
| | | | | | We will use it from the MinGW port's gettimeofday() substitution. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
* Fix approxidate("never") to always return 0Olivier Marin2008-06-17
| | | | | | | | | | | | | Commit af66366a9feb0194ed04b1f538998021ece268a8 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>
* timezone_names[]: fixed the tz offset for New Zealand.Steven Drake2008-02-25
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse_date_format(): convert a format name to an enum date_modeAndy Parkins2007-09-29
| | | | | | | | | | | | | | | | | | 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>
* Teach approxidate() to understand "never"Johannes Schindelin2007-07-24
| | | | | | | | | | | | 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>
* Make show_rfc2822_date() just another date output format.Junio C Hamano2007-07-13
| | | | | | | | | | | 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>
* Support output ISO 8601 format datesRobin Rosenberg2007-07-13
| | | | | | | | 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>
* War on whitespaceJunio C Hamano2007-06-07
| | | | | | | | | 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>
* Accept dates before 2000/01/01 when specified as seconds since the epochJohannes Sixt2007-06-06
| | | | | | | | | | | | 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>
* Add --date={local,relative,default}Junio C Hamano2007-04-25
| | | | | | | | | | | 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>
* show_date(): rename the "relative" parameter to "mode"Johannes Schindelin2007-02-27
| | | | | | | | | | | | | | | | 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>
* show_date(): fix relative datesJohannes Schindelin2007-01-20
| | | | | | | | 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>
* simplify inclusion of system header files.Junio C Hamano2006-12-20
| | | | | | | | | | | | | | | | | | | | 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>
* Fix approxidate() to understand 12:34 AM/PM are 00:34 and 12:34Linus Torvalds2006-09-29
| | | | | | | | | | | | | | | | 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>
* Fix approxidate() to understand more extended numbersLinus Torvalds2006-09-28
| | | | | | | 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>
* Clean up approxidate() in preparation for fixesLinus Torvalds2006-09-28
| | | | | | | | | | 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>
* Relative timestamps in git logLinus Torvalds2006-08-26
| | | | | | | | | | | | | | | | | | | | | 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>
* n is in fact unused, and is later shadowed.Pierre Habouzit2006-08-23
| | | | | | | | 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>
* date.c: improve guess between timezone offset and year.Paul Eggert2006-06-08
| | | | | | | | | | | | | | 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>
* Use RFC2822 dates from "git fmt-patch".Junio C Hamano2006-05-01
| | | | | | | | | 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 262a6ef76a1dde97ab50d79fa5cd6d3f9f125765 commit to use RFC2822 date format. Signed-off-by: Junio C Hamano <junkio@cox.net>
* date parsing: be friendlier to our European friends.Junio C Hamano2006-04-05
| | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'fix'Junio C Hamano2006-04-05
|\ | | | | | | | | | | * fix: diff_flush(): leakfix. parse_date(): fix parsing 03/10/2006
| * parse_date(): fix parsing 03/10/2006Junio C Hamano2006-04-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Use #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))Junio C Hamano2006-03-09
|/ | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix nasty approxidate bugLinus Torvalds2006-01-05
| | | | | | | | | | | | | | | | | | | | | Stupid me. If approxidate ends up with a month that is ahead of the current month, it decrements the year to last year. Which is correct, and means that "last december" does the right thing. HOWEVER. It should only do so if the year is the same as the current year. Without this fix, "5 days ago" ends up being in 2004, because it first decrements five days, getting us to December 2005 (correct), but then it also ends up decrementing the year once more to turn that December into "last year" (incorrect, since it already _was_ last year). Duh. Pass me a donut. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* code comments: spellJunio C Hamano2005-12-29
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Teach "approxidate" about weekday syntaxLinus Torvalds2005-11-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Fri, 18 Nov 2005, David Roundy wrote: > > Don't forget "high noon"! (and perhaps "tea time"?) :) Done. [torvalds@g5 git]$ ./test-date "now" "midnight" "high noon" "tea-time" now -> bad -> Wed Dec 31 16:00:00 1969 now -> Fri Nov 18 08:50:54 2005 midnight -> bad -> Wed Dec 31 16:00:00 1969 midnight -> Fri Nov 18 00:00:00 2005 high noon -> bad -> Wed Dec 31 16:00:00 1969 high noon -> Thu Nov 17 12:00:00 2005 tea-time -> bad -> Wed Dec 31 16:00:00 1969 tea-time -> Thu Nov 17 17:00:00 2005 Thanks for pointing out tea-time. This is also written to easily extended to allow people to add their own important dates like Christmas and their own birthdays. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-09 06:12:24 +0000