summaryrefslogtreecommitdiff
path: root/date.c
Commit message (Collapse)AuthorAgeFilesLines
...
* | Add --date={local,relative,default}Junio C Hamano2007-04-251-2/+33
| | | | | | | | | | | | | | | | | | | | | | 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-271-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-201-3/+2
| | | | | | | | | | | | | | | | 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-201-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-291-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-281-0/+40
| | | | | | | | | | | | | | 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-281-3/+10
| | | | | | | | | | | | | | | | | | | | 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-261-8/+55
|/ | | | | | | | | | | | | | | | | | | | | 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-231-3/+3
| | | | | | | | 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-081-1/+1
| | | | | | | | | | | | | | 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-011-4/+25
| | | | | | | | | 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-051-21/+56
| | | | | | | | | | | | | | | | | | | | 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-051-2/+2
|\ | | | | | | | | | | * fix: diff_flush(): leakfix. parse_date(): fix parsing 03/10/2006
| * parse_date(): fix parsing 03/10/2006Junio C Hamano2006-04-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-091-3/+1
|/ | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix nasty approxidate bugLinus Torvalds2006-01-051-1/+1
| | | | | | | | | | | | | | | | | | | | | 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-291-1/+1
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Teach "approxidate" about weekday syntaxLinus Torvalds2005-11-181-5/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Teach "approxidate" about weekday syntaxLinus Torvalds2005-11-171-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* git's rev-parse.c function show_datestring presumes gnu dateLinus Torvalds2005-11-161-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Unlocalized isspace and friendsLinus Torvalds2005-10-141-1/+0
| | | | | | | | | 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>
* [PATCH] Fix strange timezone handlingLinus Torvalds2005-09-221-10/+14
| | | | | | | | | | | | | | | | | | | | | | 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>
* [PATCH] Return proper error valud from "parse_date()"Linus Torvalds2005-09-201-3/+3
| | | | | | | | | | | | | | | | | | | 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>
* parse_date(): allow const date stringLinus Torvalds2005-07-121-4/+4
| | | | This is part of breaking up the tag ID patch by Eric Biederman.
* [PATCH] fix date parsing for GIT raw commit timestamp format.Junio C Hamano2005-06-251-5/+9
| | | | | | | | | | | | | | | | | | | | 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>
* Include file cleanups..Linus Torvalds2005-05-221-3/+0
| | | | | | | 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.
* sparse cleanupLinus Torvalds2005-05-201-0/+2
| | | | | | | | | 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.
* [PATCH] fix show_date() for positive timezonesNicolas Pitre2005-05-181-2/+2
| | | | | Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* date.c: add "show_date()" function.Linus Torvalds2005-05-061-0/+28
| | | | Kind of like ctime(), but not as broken.
* date handling: handle "AM"/"PM" on timeLinus Torvalds2005-05-011-8/+22
| | | | | | | | 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.
* date.c: allow even more varied time formatsLinus Torvalds2005-05-011-54/+152
| | | | (and some added checks for truly non-sensical stuff)
* date.c: fix printout of timezone offsets that aren't exact hoursLinus Torvalds2005-04-301-2/+8
| | | | We'd get the sign wrong for the minutes part of a negative offset.
* date.c: only use the TZ names if we don't have anything better.Linus Torvalds2005-04-301-1/+5
| | | | Also, add EEST (hey, it's Finland).
* date.c: split up dst information in the timezone tableLinus Torvalds2005-04-301-45/+51
| | | | | | | | | 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.
* date.c: fix parsing of dates in mm/dd/yy formatLinus Torvalds2005-04-301-1/+3
| | | | | We looked at the year one character too early, and we didn't accept a two-character year date after 2000.
* date.c: use the local timezone if none specifiedLinus Torvalds2005-04-301-2/+7
|
* Make the date parsing accept pretty much any random crap.Linus Torvalds2005-04-301-106/+215
| | | | This date parser turns line-noise into a date. Cool.
* [PATCH] Do date parsing by hand...Edgar Toernig2005-04-301-0/+184
...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.
View Lorry Controller Status