kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
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>	19 years ago
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>	19 years ago
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>	19 years ago
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>	19 years ago
Junio C Hamano	b4f2a6ac92	Use #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0])) Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	b73cebf437	Fix nasty approxidate bug 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>	19 years ago
Junio C Hamano	82f9d58a39	code comments: spell Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	a8aca418d6	Teach "approxidate" about weekday syntax 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>	19 years ago
Linus Torvalds	6b7b042772	Teach "approxidate" about weekday syntax This allows people to use syntax like "last thursday" for the approxidate. (Or, indeed, more complex "three thursdays ago", but I suspect that would be pretty unusual). NOTE! The parsing is strictly sequential, so if you do "one day before last thursday" it will _not_ do what you think it does. It will take the current time, subtract one day, and then go back to the thursday before that. So to get what you want, you'd have to write it the other way around: "last thursday and one day before" which is insane (it's usually the same as "last wednesday" _except_ if today is Thursday, in which case "last wednesday" is yesterday, and "last thursday and one day before" is eight days ago). Similarly, "last thursday one month ago" will first go back to last thursday, and then go back one month from there, not the other way around. I doubt anybody would ever use insane dates like that, but I thought I'd point out that the approxidate parsing is not exactly "standard English". Side note 2: if you want to avoid spaces (because of quoting issues), you can use any non-alphanumberic character instead. So git log --since=2.days.ago works without any quotes. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	3c07b1d194	git's rev-parse.c function show_datestring presumes gnu date Ok. This is the insane patch to do this. It really isn't very careful, and the reason I call it "approxidate()" will become obvious when you look at the code. It is very liberal in what it accepts, to the point where sometimes the results may not make a whole lot of sense. It accepts "last week" as a date string, by virtue of "last" parsing as the number 1, and it totally ignoring superfluous fluff like "ago", so "last week" ends up being exactly the same thing as "1 week ago". Fine so far. It has strange side effects: "last december" will actually parse as "Dec 1", which actually _does_ turn out right, because it will then notice that it's not December yet, so it will decide that you must be talking about a date last year. So it actually gets it right, but it's kind of for the "wrong" reasons. It also accepts the numbers 1..10 in string format ("one" .. "ten"), so you can do "ten weeks ago" or "ten hours ago" and it will do the right thing. But it will do some really strange thigns too: the string "this will last forever", will not recognize anyting but "last", which is recognized as "1", which since it doesn't understand anything else it will think is the day of the month. So if you do gitk --since="this will last forever" the date will actually parse as the first day of the current month. And it will parse the string "now" as "now", but only because it doesn't understand it at all, and it makes everything relative to "now". Similarly, it doesn't actually parse the "ago" or "from now", so "2 weeks ago" is exactly the same as "2 weeks from now". It's the current date minus 14 days. But hey, it's probably better (and certainly faster) than depending on GNU date. So now you can portably do things like gitk --since="two weeks and three days ago" git log --since="July 5" git-whatchanged --since="10 hours ago" git log --since="last october" and it will actually do exactly what you thought it would do (I think). It will count 17 days backwards, and it will do so even if you don't have GNU date installed. (I don't do "last monday" or similar yet, but I can extend it to that too if people want). It was kind of fun trying to write code that uses such totally relaxed "understanding" of dates yet tries to get it right for the trivial cases. The result should be mixed with a few strange preprocessor tricks, and be submitted for the IOCCC ;) Feel free to try it out, and see how many strange dates it gets right. Or wrong. And if you find some interesting (and valid - not "interesting" as in "strange", but "interesting" as in "I'd be interested in actually doing this) thing it gets wrong - usually by not understanding it and silently just doing some strange things - please holler. Now, as usual this certainly hasn't been getting a lot of testing. But my code always works, no? Linus Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	4546738b58	Unlocalized isspace and friends Do our own ctype.h, just to get the sane semantics: we want locale-independence, _and_ we want the right signed behaviour. Plus we only use a very small subset of ctype.h anyway (isspace, isalpha, isdigit and isalnum). Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Linus Torvalds	01c6ad29bd	[PATCH] Fix strange timezone handling We generate the ASCII representation of our internal date representation ("seconds since 1970, UTC + timezone information") in two different places. One of them uses the stupid and obvious way to make sure that it gets the sexagecimal representation right for negative timezones even if they might not be exact hours, and the other one depends on the modulus operator always matching the sign of argument. Hey, the clever one works. And C90 even specifies that behaviour. But I had to think about it for a while when I was re-visiting this area, and even if I didn't have to, it's kind of strange to have two different ways to print out the same data format. So use a common helper for this. And select the stupid and straighforward way. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Linus Torvalds	2a39064c65	[PATCH] Return proper error valud from "parse_date()" Right now we don't return any error value at all from parse_date(), and if we can't parse it, we just silently leave the result buffer unchanged. That's fine for the current user, which will always default to the current date, but it's a crappy interface, and we might well be better off with an error message rather than just the default date. So let's change the thing to return a negative value if an error occurs, and the length of the result otherwise (snprintf behaviour: if the buffer is too small, it returns how big it _would_ have been). [ I started looking at this in case we could support date-based revision names. Looks ugly. Would have to parse relative dates.. ] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	20 years ago
Linus Torvalds	26a2d8ae89	parse_date(): allow const date string This is part of breaking up the tag ID patch by Eric Biederman.	20 years ago
Junio C Hamano	9cb480f2ad	[PATCH] fix date parsing for GIT raw commit timestamp format. Usually all of the match_xxx routines in date.c fill tm structure assuming that the parsed string talks about local time, and parse_date routine compensates for it by adjusting the value with tz offset parsed out separately. However, this logic does not work well when we feed GIT raw commit timestamp to it, because what match_digits gets is already in GMT. A good testcase is: $ make test-date $ ./test-date 'Fri Jun 24 16:55:27 2005 -0700' '1119657327 -0700' These two timestamps represent the same time, but the second one without the fix this commit introduces gives you 7 hours off. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Linus Torvalds	6b0c312106	Include file cleanups.. Add <limits.h> to the include files handled by "cache.h", and remove extraneous #include directives from various .c files. The rule is that "cache.h" gets all the basic stuff, so that we'll have as few system dependencies as possible.	20 years ago
Linus Torvalds	e99d59ff0b	sparse cleanup Fix various things that sparse complains about: - use NULL instead of 0 - make sure we declare everything properly, or mark it static - use proper function declarations ("fn(void)" instead of "fn()") Sparse is always right.	20 years ago
Nicolas Pitre	fbab835c03	[PATCH] fix show_date() for positive timezones Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>	20 years ago
Linus Torvalds	f80cd783c6	date.c: add "show_date()" function. Kind of like ctime(), but not as broken.	20 years ago
Linus Torvalds	68849b5442	date handling: handle "AM"/"PM" on time And be a bitmore careful about matching: if we don't recognize a word or a number, we skip the whole thing, rather than trying the next character in that word/number. Finally: since ctime() adds the final '\n', don't add another one in test-date.	20 years ago
Linus Torvalds	198b0fb635	date.c: allow even more varied time formats (and some added checks for truly non-sensical stuff)	20 years ago
Linus Torvalds	7f26664f1f	date.c: fix printout of timezone offsets that aren't exact hours We'd get the sign wrong for the minutes part of a negative offset.	20 years ago
Linus Torvalds	92e2311b6c	date.c: only use the TZ names if we don't have anything better. Also, add EEST (hey, it's Finland).	20 years ago
Linus Torvalds	5e2a78a410	date.c: split up dst information in the timezone table This still doesn't actually really _use_ it properly, nor make any distinction between different DST rules, but at least we could (if we wanted to) fake it a bit better. Right now the code actually still says "it's always summer". I'm from Finland, I don't like winter.	20 years ago
Linus Torvalds	a90588821a	date.c: fix parsing of dates in mm/dd/yy format We looked at the year one character too early, and we didn't accept a two-character year date after 2000.	20 years ago
Linus Torvalds	eaa8512923	date.c: use the local timezone if none specified	20 years ago
Linus Torvalds	89967023da	Make the date parsing accept pretty much any random crap. This date parser turns line-noise into a date. Cool.	20 years ago
Edgar Toernig	ecee9d9e79	[PATCH] Do date parsing by hand... ...since everything out there is either strange (libc mktime has issues with timezones) or introduces unnecessary dependencies for people (libcurl). This goes back to the old date parsing, but moves it out into a file of its own, and does the "struct tm" to "seconds since epoch" handling by hand. I grepped through the tz-database and it seems there's one "country" left that has non-60-minute DST: Lord Howe Island. All others dropped that before 1970.	20 years ago

29 Commits (f5fffbd3e878d2be4154174c588a229ca37b04f1)