2005-04-30 16:46:49 +00:00
|
|
|
/*
|
|
|
|
* GIT - The information manager from hell
|
|
|
|
*
|
|
|
|
* Copyright (C) Linus Torvalds, 2005
|
|
|
|
*/
|
|
|
|
|
2005-05-20 18:46:10 +00:00
|
|
|
#include "cache.h"
|
|
|
|
|
2008-06-23 06:31:41 +00:00
|
|
|
/*
|
|
|
|
* This is like mktime, but without normalization of tm_wday and tm_yday.
|
|
|
|
*/
|
2010-01-12 07:52:47 +00:00
|
|
|
static time_t tm_to_time_t(const struct tm *tm)
|
2005-04-30 16:46:49 +00:00
|
|
|
{
|
|
|
|
static const int mdays[] = {
|
|
|
|
0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334
|
|
|
|
};
|
|
|
|
int year = tm->tm_year - 70;
|
|
|
|
int month = tm->tm_mon;
|
|
|
|
int day = tm->tm_mday;
|
|
|
|
|
|
|
|
if (year < 0 || year > 129) /* algo only works for 1970-2099 */
|
|
|
|
return -1;
|
|
|
|
if (month < 0 || month > 11) /* array bounds */
|
|
|
|
return -1;
|
|
|
|
if (month < 2 || (year + 2) % 4)
|
|
|
|
day--;
|
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-23 01:11:44 +00:00
|
|
|
if (tm->tm_hour < 0 || tm->tm_min < 0 || tm->tm_sec < 0)
|
|
|
|
return -1;
|
2005-04-30 16:46:49 +00:00
|
|
|
return (year * 365 + (year + 1) / 4 + mdays[month] + day) * 24*60*60UL +
|
|
|
|
tm->tm_hour * 60*60 + tm->tm_min * 60 + tm->tm_sec;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *month_names[] = {
|
2005-04-30 20:19:56 +00:00
|
|
|
"January", "February", "March", "April", "May", "June",
|
|
|
|
"July", "August", "September", "October", "November", "December"
|
2005-04-30 16:46:49 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const char *weekday_names[] = {
|
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>
2005-11-17 20:36:30 +00:00
|
|
|
"Sundays", "Mondays", "Tuesdays", "Wednesdays", "Thursdays", "Fridays", "Saturdays"
|
2005-04-30 16:46:49 +00:00
|
|
|
};
|
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
static time_t gm_time_t(timestamp_t time, int tz)
|
2006-08-26 22:45:26 +00:00
|
|
|
{
|
|
|
|
int minutes;
|
|
|
|
|
|
|
|
minutes = tz < 0 ? -tz : tz;
|
|
|
|
minutes = (minutes / 100)*60 + (minutes % 100);
|
|
|
|
minutes = tz < 0 ? -minutes : minutes;
|
2017-04-26 19:29:36 +00:00
|
|
|
|
|
|
|
if (minutes > 0) {
|
|
|
|
if (unsigned_add_overflows(time, minutes * 60))
|
|
|
|
die("Timestamp+tz too large: %"PRItime" +%04d",
|
|
|
|
time, tz);
|
|
|
|
} else if (time < -minutes * 60)
|
|
|
|
die("Timestamp before Unix epoch: %"PRItime" %04d", time, tz);
|
|
|
|
time += minutes * 60;
|
|
|
|
if (date_overflows(time))
|
|
|
|
die("Timestamp too large for this system: %"PRItime, time);
|
|
|
|
return (time_t)time;
|
2006-08-26 22:45:26 +00:00
|
|
|
}
|
|
|
|
|
2005-05-06 22:28:59 +00:00
|
|
|
/*
|
|
|
|
* The "tz" thing is passed in as this strange "decimal parse of tz"
|
|
|
|
* thing, which means that tz -0100 is passed in as the integer -100,
|
|
|
|
* even though it means "sixty minutes off"
|
|
|
|
*/
|
2019-11-28 12:25:03 +00:00
|
|
|
static struct tm *time_to_tm(timestamp_t time, int tz, struct tm *tm)
|
2005-05-06 22:28:59 +00:00
|
|
|
{
|
2006-08-26 22:45:26 +00:00
|
|
|
time_t t = gm_time_t(time, tz);
|
2019-11-28 12:25:03 +00:00
|
|
|
return gmtime_r(&t, tm);
|
2006-05-01 08:44:33 +00:00
|
|
|
}
|
|
|
|
|
2019-11-28 12:25:03 +00:00
|
|
|
static struct tm *time_to_tm_local(timestamp_t time, struct tm *tm)
|
date: use localtime() for "-local" time formats
When we convert seconds-since-epochs timestamps into a
broken-down "struct tm", we do so by adjusting the timestamp
according to the known offset and then using gmtime() to
break down the result. This means that the resulting struct
"knows" that it's in GMT, even though the time it represents
is adjusted for a different zone. The fields where it stores
this data are not portably accessible, so we have no way to
override them to tell them the real zone info.
For the most part, this works. Our date-formatting routines
don't pay attention to these inaccessible fields, and use
the same tz info we provided for adjustment. The one
exception is when we call strftime(), whose %Z format
reveals this hidden timezone data.
We solved that by always showing the empty string for %Z.
This is allowed by POSIX, but not very helpful to the user.
We can't make this work in the general case, as there's no
portable function for setting an arbitrary timezone (and
anyway, we don't have the zone name for the author zones,
only their offsets).
But for the special case of the "-local" formats, we can
just skip the adjustment and use localtime() instead of
gmtime(). This makes --date=format-local:%Z work correctly,
showing the local timezone instead of an empty string.
The new test checks the result for "UTC", our default
test-lib value for $TZ. Using something like EST5 might be
more interesting, but the actual zone string is
system-dependent (for instance, on my system it expands to
just EST). Hopefully "UTC" is vanilla enough that every
system treats it the same.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 13:52:17 +00:00
|
|
|
{
|
|
|
|
time_t t = time;
|
2019-11-28 12:25:03 +00:00
|
|
|
return localtime_r(&t, tm);
|
date: use localtime() for "-local" time formats
When we convert seconds-since-epochs timestamps into a
broken-down "struct tm", we do so by adjusting the timestamp
according to the known offset and then using gmtime() to
break down the result. This means that the resulting struct
"knows" that it's in GMT, even though the time it represents
is adjusted for a different zone. The fields where it stores
this data are not portably accessible, so we have no way to
override them to tell them the real zone info.
For the most part, this works. Our date-formatting routines
don't pay attention to these inaccessible fields, and use
the same tz info we provided for adjustment. The one
exception is when we call strftime(), whose %Z format
reveals this hidden timezone data.
We solved that by always showing the empty string for %Z.
This is allowed by POSIX, but not very helpful to the user.
We can't make this work in the general case, as there's no
portable function for setting an arbitrary timezone (and
anyway, we don't have the zone name for the author zones,
only their offsets).
But for the special case of the "-local" formats, we can
just skip the adjustment and use localtime() instead of
gmtime(). This makes --date=format-local:%Z work correctly,
showing the local timezone instead of an empty string.
The new test checks the result for "UTC", our default
test-lib value for $TZ. Using something like EST5 might be
more interesting, but the actual zone string is
system-dependent (for instance, on my system it expands to
just EST). Hopefully "UTC" is vanilla enough that every
system treats it the same.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 13:52:17 +00:00
|
|
|
}
|
|
|
|
|
2007-04-25 06:36:22 +00:00
|
|
|
/*
|
2019-01-18 06:18:01 +00:00
|
|
|
* Fill in the localtime 'struct tm' for the supplied time,
|
|
|
|
* and return the local tz.
|
2007-04-25 06:36:22 +00:00
|
|
|
*/
|
2019-01-18 06:18:01 +00:00
|
|
|
static int local_time_tzoffset(time_t t, struct tm *tm)
|
2007-04-25 06:36:22 +00:00
|
|
|
{
|
2019-01-18 06:18:01 +00:00
|
|
|
time_t t_local;
|
2007-04-25 06:36:22 +00:00
|
|
|
int offset, eastwest;
|
|
|
|
|
2019-01-18 06:18:01 +00:00
|
|
|
localtime_r(&t, tm);
|
|
|
|
t_local = tm_to_time_t(tm);
|
local_tzoffset: detect errors from tm_to_time_t
When we want to know the local timezone offset at a given
timestamp, we compute it by asking for localtime() at the
given time, and comparing the offset to GMT at that time.
However, there's some juggling between time_t and "struct
tm" which happens, which involves calling our own
tm_to_time_t().
If that function returns an error (e.g., because it only
handles dates up to the year 2099), it returns "-1", which
we treat as a time_t, and is clearly bogus, leading to
bizarre timestamps (that seem to always adjust the time back
to (time_t)(uint32_t)-1, in the year 2106).
It's not a good idea for local_tzoffset() to simply die
here; it would make it hard to run "git log" on a repository
with funny timestamps. Instead, let's just treat such cases
as "zero offset".
Reported-by: Norbert Kiesel <nkiesel@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20 21:14:14 +00:00
|
|
|
if (t_local == -1)
|
|
|
|
return 0; /* error; just use +0000 */
|
2007-04-25 06:36:22 +00:00
|
|
|
if (t_local < t) {
|
|
|
|
eastwest = -1;
|
|
|
|
offset = t - t_local;
|
|
|
|
} else {
|
|
|
|
eastwest = 1;
|
|
|
|
offset = t_local - t;
|
|
|
|
}
|
|
|
|
offset /= 60; /* in minutes */
|
|
|
|
offset = (offset % 60) + ((offset / 60) * 100);
|
|
|
|
return offset * eastwest;
|
|
|
|
}
|
|
|
|
|
2019-01-18 06:18:01 +00:00
|
|
|
/*
|
|
|
|
* What value of "tz" was in effect back then at "time" in the
|
|
|
|
* local timezone?
|
|
|
|
*/
|
|
|
|
static int local_tzoffset(timestamp_t time)
|
|
|
|
{
|
|
|
|
struct tm tm;
|
|
|
|
|
|
|
|
if (date_overflows(time))
|
|
|
|
die("Timestamp too large for this system: %"PRItime, time);
|
|
|
|
|
|
|
|
return local_time_tzoffset((time_t)time, &tm);
|
|
|
|
}
|
|
|
|
|
2019-01-29 03:50:15 +00:00
|
|
|
static void get_time(struct timeval *now)
|
|
|
|
{
|
|
|
|
const char *x;
|
|
|
|
|
|
|
|
x = getenv("GIT_TEST_DATE_NOW");
|
|
|
|
if (x) {
|
|
|
|
now->tv_sec = atoi(x);
|
|
|
|
now->tv_usec = 0;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
gettimeofday(now, NULL);
|
|
|
|
}
|
|
|
|
|
2019-09-12 04:11:01 +00:00
|
|
|
void show_date_relative(timestamp_t time, struct strbuf *timebuf)
|
2009-08-31 02:26:05 +00:00
|
|
|
{
|
2019-09-12 04:11:01 +00:00
|
|
|
struct timeval now;
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t diff;
|
2019-09-12 04:11:01 +00:00
|
|
|
|
|
|
|
get_time(&now);
|
|
|
|
if (now.tv_sec < time) {
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addstr(timebuf, _("in the future"));
|
|
|
|
return;
|
|
|
|
}
|
2019-09-12 04:11:01 +00:00
|
|
|
diff = now.tv_sec - time;
|
2009-08-31 02:26:05 +00:00
|
|
|
if (diff < 90) {
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(timebuf,
|
2017-04-21 10:45:48 +00:00
|
|
|
Q_("%"PRItime" second ago", "%"PRItime" seconds ago", diff), diff);
|
2012-04-23 12:30:23 +00:00
|
|
|
return;
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
|
|
|
/* Turn it into minutes */
|
|
|
|
diff = (diff + 30) / 60;
|
|
|
|
if (diff < 90) {
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(timebuf,
|
2017-04-21 10:45:48 +00:00
|
|
|
Q_("%"PRItime" minute ago", "%"PRItime" minutes ago", diff), diff);
|
2012-04-23 12:30:23 +00:00
|
|
|
return;
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
|
|
|
/* Turn it into hours */
|
|
|
|
diff = (diff + 30) / 60;
|
|
|
|
if (diff < 36) {
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(timebuf,
|
2017-04-21 10:45:48 +00:00
|
|
|
Q_("%"PRItime" hour ago", "%"PRItime" hours ago", diff), diff);
|
2012-04-23 12:30:23 +00:00
|
|
|
return;
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
|
|
|
/* We deal with number of days from here on */
|
|
|
|
diff = (diff + 12) / 24;
|
|
|
|
if (diff < 14) {
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(timebuf,
|
2017-04-21 10:45:48 +00:00
|
|
|
Q_("%"PRItime" day ago", "%"PRItime" days ago", diff), diff);
|
2012-04-23 12:30:23 +00:00
|
|
|
return;
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
|
|
|
/* Say weeks for the past 10 weeks or so */
|
|
|
|
if (diff < 70) {
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(timebuf,
|
2017-04-21 10:45:48 +00:00
|
|
|
Q_("%"PRItime" week ago", "%"PRItime" weeks ago", (diff + 3) / 7),
|
2012-04-23 12:30:23 +00:00
|
|
|
(diff + 3) / 7);
|
|
|
|
return;
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
|
|
|
/* Say months for the past 12 months or so */
|
2009-10-03 04:20:18 +00:00
|
|
|
if (diff < 365) {
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(timebuf,
|
2017-04-21 10:45:48 +00:00
|
|
|
Q_("%"PRItime" month ago", "%"PRItime" months ago", (diff + 15) / 30),
|
2012-04-23 12:30:23 +00:00
|
|
|
(diff + 15) / 30);
|
|
|
|
return;
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
|
|
|
/* Give years and months for 5 years or so */
|
|
|
|
if (diff < 1825) {
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t totalmonths = (diff * 12 * 2 + 365) / (365 * 2);
|
|
|
|
timestamp_t years = totalmonths / 12;
|
|
|
|
timestamp_t months = totalmonths % 12;
|
2012-04-23 12:30:23 +00:00
|
|
|
if (months) {
|
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2017-04-21 10:45:48 +00:00
|
|
|
strbuf_addf(&sb, Q_("%"PRItime" year", "%"PRItime" years", years), years);
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(timebuf,
|
2014-04-17 05:37:17 +00:00
|
|
|
/* TRANSLATORS: "%s" is "<n> years" */
|
2017-04-21 10:45:48 +00:00
|
|
|
Q_("%s, %"PRItime" month ago", "%s, %"PRItime" months ago", months),
|
2012-04-23 12:30:23 +00:00
|
|
|
sb.buf, months);
|
|
|
|
strbuf_release(&sb);
|
|
|
|
} else
|
|
|
|
strbuf_addf(timebuf,
|
2017-04-21 10:45:48 +00:00
|
|
|
Q_("%"PRItime" year ago", "%"PRItime" years ago", years), years);
|
2012-04-23 12:30:23 +00:00
|
|
|
return;
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
|
|
|
/* Otherwise, just years. Centuries is probably overkill. */
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(timebuf,
|
2017-04-21 10:45:48 +00:00
|
|
|
Q_("%"PRItime" year ago", "%"PRItime" years ago", (diff + 183) / 365),
|
2012-04-23 12:30:23 +00:00
|
|
|
(diff + 183) / 365);
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
|
|
|
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
struct date_mode *date_mode_from_type(enum date_mode_type type)
|
|
|
|
{
|
|
|
|
static struct date_mode mode;
|
2015-06-25 16:55:45 +00:00
|
|
|
if (type == DATE_STRFTIME)
|
2018-05-02 09:38:39 +00:00
|
|
|
BUG("cannot create anonymous strftime date_mode struct");
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
mode.type = type;
|
2015-09-03 21:48:59 +00:00
|
|
|
mode.local = 0;
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
return &mode;
|
|
|
|
}
|
|
|
|
|
2019-01-18 06:18:01 +00:00
|
|
|
static void show_date_normal(struct strbuf *buf, timestamp_t time, struct tm *tm, int tz, struct tm *human_tm, int human_tz, int local)
|
|
|
|
{
|
|
|
|
struct {
|
|
|
|
unsigned int year:1,
|
|
|
|
date:1,
|
|
|
|
wday:1,
|
|
|
|
time:1,
|
|
|
|
seconds:1,
|
|
|
|
tz:1;
|
|
|
|
} hide = { 0 };
|
|
|
|
|
|
|
|
hide.tz = local || tz == human_tz;
|
|
|
|
hide.year = tm->tm_year == human_tm->tm_year;
|
|
|
|
if (hide.year) {
|
|
|
|
if (tm->tm_mon == human_tm->tm_mon) {
|
|
|
|
if (tm->tm_mday > human_tm->tm_mday) {
|
|
|
|
/* Future date: think timezones */
|
|
|
|
} else if (tm->tm_mday == human_tm->tm_mday) {
|
|
|
|
hide.date = hide.wday = 1;
|
|
|
|
} else if (tm->tm_mday + 5 > human_tm->tm_mday) {
|
|
|
|
/* Leave just weekday if it was a few days ago */
|
|
|
|
hide.date = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Show "today" times as just relative times */
|
|
|
|
if (hide.wday) {
|
2019-09-12 04:11:01 +00:00
|
|
|
show_date_relative(time, buf);
|
2019-01-18 06:18:01 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Always hide seconds for human-readable.
|
|
|
|
* Hide timezone if showing date.
|
|
|
|
* Hide weekday and time if showing year.
|
|
|
|
*
|
|
|
|
* The logic here is two-fold:
|
|
|
|
* (a) only show details when recent enough to matter
|
|
|
|
* (b) keep the maximum length "similar", and in check
|
|
|
|
*/
|
|
|
|
if (human_tm->tm_year) {
|
|
|
|
hide.seconds = 1;
|
|
|
|
hide.tz |= !hide.date;
|
|
|
|
hide.wday = hide.time = !hide.year;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!hide.wday)
|
|
|
|
strbuf_addf(buf, "%.3s ", weekday_names[tm->tm_wday]);
|
|
|
|
if (!hide.date)
|
|
|
|
strbuf_addf(buf, "%.3s %d ", month_names[tm->tm_mon], tm->tm_mday);
|
|
|
|
|
|
|
|
/* Do we want AM/PM depending on locale? */
|
|
|
|
if (!hide.time) {
|
|
|
|
strbuf_addf(buf, "%02d:%02d", tm->tm_hour, tm->tm_min);
|
|
|
|
if (!hide.seconds)
|
|
|
|
strbuf_addf(buf, ":%02d", tm->tm_sec);
|
|
|
|
} else
|
|
|
|
strbuf_rtrim(buf);
|
|
|
|
|
|
|
|
if (!hide.year)
|
|
|
|
strbuf_addf(buf, " %d", tm->tm_year + 1900);
|
|
|
|
|
|
|
|
if (!hide.tz)
|
|
|
|
strbuf_addf(buf, " %+05d", tz);
|
|
|
|
}
|
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
const char *show_date(timestamp_t time, int tz, const struct date_mode *mode)
|
2006-05-01 08:44:33 +00:00
|
|
|
{
|
|
|
|
struct tm *tm;
|
2019-11-28 12:25:03 +00:00
|
|
|
struct tm tmbuf = { 0 };
|
2019-01-18 06:18:01 +00:00
|
|
|
struct tm human_tm = { 0 };
|
|
|
|
int human_tz = -1;
|
2012-04-23 12:30:23 +00:00
|
|
|
static struct strbuf timebuf = STRBUF_INIT;
|
2006-05-01 08:44:33 +00:00
|
|
|
|
2016-07-22 19:51:49 +00:00
|
|
|
if (mode->type == DATE_UNIX) {
|
|
|
|
strbuf_reset(&timebuf);
|
2017-04-21 10:45:48 +00:00
|
|
|
strbuf_addf(&timebuf, "%"PRItime, time);
|
2016-07-22 19:51:49 +00:00
|
|
|
return timebuf.buf;
|
|
|
|
}
|
|
|
|
|
2019-01-18 06:18:01 +00:00
|
|
|
if (mode->type == DATE_HUMAN) {
|
|
|
|
struct timeval now;
|
|
|
|
|
2019-01-29 03:50:15 +00:00
|
|
|
get_time(&now);
|
2019-01-18 06:18:01 +00:00
|
|
|
|
|
|
|
/* Fill in the data for "current time" in human_tz and human_tm */
|
|
|
|
human_tz = local_time_tzoffset(now.tv_sec, &human_tm);
|
|
|
|
}
|
|
|
|
|
2015-09-03 21:48:59 +00:00
|
|
|
if (mode->local)
|
2015-09-03 21:48:58 +00:00
|
|
|
tz = local_tzoffset(time);
|
|
|
|
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
if (mode->type == DATE_RAW) {
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_reset(&timebuf);
|
2017-04-21 10:45:48 +00:00
|
|
|
strbuf_addf(&timebuf, "%"PRItime" %+05d", time, tz);
|
2012-04-23 12:30:23 +00:00
|
|
|
return timebuf.buf;
|
2009-02-20 22:15:22 +00:00
|
|
|
}
|
|
|
|
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
if (mode->type == DATE_RELATIVE) {
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_reset(&timebuf);
|
2019-09-12 04:11:01 +00:00
|
|
|
show_date_relative(time, &timebuf);
|
2012-04-23 12:30:23 +00:00
|
|
|
return timebuf.buf;
|
2006-08-26 22:45:26 +00:00
|
|
|
}
|
|
|
|
|
date: use localtime() for "-local" time formats
When we convert seconds-since-epochs timestamps into a
broken-down "struct tm", we do so by adjusting the timestamp
according to the known offset and then using gmtime() to
break down the result. This means that the resulting struct
"knows" that it's in GMT, even though the time it represents
is adjusted for a different zone. The fields where it stores
this data are not portably accessible, so we have no way to
override them to tell them the real zone info.
For the most part, this works. Our date-formatting routines
don't pay attention to these inaccessible fields, and use
the same tz info we provided for adjustment. The one
exception is when we call strftime(), whose %Z format
reveals this hidden timezone data.
We solved that by always showing the empty string for %Z.
This is allowed by POSIX, but not very helpful to the user.
We can't make this work in the general case, as there's no
portable function for setting an arbitrary timezone (and
anyway, we don't have the zone name for the author zones,
only their offsets).
But for the special case of the "-local" formats, we can
just skip the adjustment and use localtime() instead of
gmtime(). This makes --date=format-local:%Z work correctly,
showing the local timezone instead of an empty string.
The new test checks the result for "UTC", our default
test-lib value for $TZ. Using something like EST5 might be
more interesting, but the actual zone string is
system-dependent (for instance, on my system it expands to
just EST). Hopefully "UTC" is vanilla enough that every
system treats it the same.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 13:52:17 +00:00
|
|
|
if (mode->local)
|
2019-11-28 12:25:03 +00:00
|
|
|
tm = time_to_tm_local(time, &tmbuf);
|
date: use localtime() for "-local" time formats
When we convert seconds-since-epochs timestamps into a
broken-down "struct tm", we do so by adjusting the timestamp
according to the known offset and then using gmtime() to
break down the result. This means that the resulting struct
"knows" that it's in GMT, even though the time it represents
is adjusted for a different zone. The fields where it stores
this data are not portably accessible, so we have no way to
override them to tell them the real zone info.
For the most part, this works. Our date-formatting routines
don't pay attention to these inaccessible fields, and use
the same tz info we provided for adjustment. The one
exception is when we call strftime(), whose %Z format
reveals this hidden timezone data.
We solved that by always showing the empty string for %Z.
This is allowed by POSIX, but not very helpful to the user.
We can't make this work in the general case, as there's no
portable function for setting an arbitrary timezone (and
anyway, we don't have the zone name for the author zones,
only their offsets).
But for the special case of the "-local" formats, we can
just skip the adjustment and use localtime() instead of
gmtime(). This makes --date=format-local:%Z work correctly,
showing the local timezone instead of an empty string.
The new test checks the result for "UTC", our default
test-lib value for $TZ. Using something like EST5 might be
more interesting, but the actual zone string is
system-dependent (for instance, on my system it expands to
just EST). Hopefully "UTC" is vanilla enough that every
system treats it the same.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 13:52:17 +00:00
|
|
|
else
|
2019-11-28 12:25:03 +00:00
|
|
|
tm = time_to_tm(time, tz, &tmbuf);
|
2014-02-24 07:49:05 +00:00
|
|
|
if (!tm) {
|
2019-11-28 12:25:03 +00:00
|
|
|
tm = time_to_tm(0, 0, &tmbuf);
|
2014-02-24 07:49:05 +00:00
|
|
|
tz = 0;
|
|
|
|
}
|
2012-04-23 12:30:23 +00:00
|
|
|
|
|
|
|
strbuf_reset(&timebuf);
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
if (mode->type == DATE_SHORT)
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(&timebuf, "%04d-%02d-%02d", tm->tm_year + 1900,
|
2007-02-27 15:21:04 +00:00
|
|
|
tm->tm_mon + 1, tm->tm_mday);
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
else if (mode->type == DATE_ISO8601)
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(&timebuf, "%04d-%02d-%02d %02d:%02d:%02d %+05d",
|
2007-07-13 23:00:42 +00:00
|
|
|
tm->tm_year + 1900,
|
|
|
|
tm->tm_mon + 1,
|
|
|
|
tm->tm_mday,
|
|
|
|
tm->tm_hour, tm->tm_min, tm->tm_sec,
|
|
|
|
tz);
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
else if (mode->type == DATE_ISO8601_STRICT) {
|
2014-08-29 16:58:42 +00:00
|
|
|
char sign = (tz >= 0) ? '+' : '-';
|
|
|
|
tz = abs(tz);
|
|
|
|
strbuf_addf(&timebuf, "%04d-%02d-%02dT%02d:%02d:%02d%c%02d:%02d",
|
|
|
|
tm->tm_year + 1900,
|
|
|
|
tm->tm_mon + 1,
|
|
|
|
tm->tm_mday,
|
|
|
|
tm->tm_hour, tm->tm_min, tm->tm_sec,
|
|
|
|
sign, tz / 100, tz % 100);
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
} else if (mode->type == DATE_RFC2822)
|
2012-04-23 12:30:23 +00:00
|
|
|
strbuf_addf(&timebuf, "%.3s, %d %.3s %d %02d:%02d:%02d %+05d",
|
2007-07-14 06:14:52 +00:00
|
|
|
weekday_names[tm->tm_wday], tm->tm_mday,
|
|
|
|
month_names[tm->tm_mon], tm->tm_year + 1900,
|
|
|
|
tm->tm_hour, tm->tm_min, tm->tm_sec, tz);
|
2015-06-25 16:55:45 +00:00
|
|
|
else if (mode->type == DATE_STRFTIME)
|
date: use localtime() for "-local" time formats
When we convert seconds-since-epochs timestamps into a
broken-down "struct tm", we do so by adjusting the timestamp
according to the known offset and then using gmtime() to
break down the result. This means that the resulting struct
"knows" that it's in GMT, even though the time it represents
is adjusted for a different zone. The fields where it stores
this data are not portably accessible, so we have no way to
override them to tell them the real zone info.
For the most part, this works. Our date-formatting routines
don't pay attention to these inaccessible fields, and use
the same tz info we provided for adjustment. The one
exception is when we call strftime(), whose %Z format
reveals this hidden timezone data.
We solved that by always showing the empty string for %Z.
This is allowed by POSIX, but not very helpful to the user.
We can't make this work in the general case, as there's no
portable function for setting an arbitrary timezone (and
anyway, we don't have the zone name for the author zones,
only their offsets).
But for the special case of the "-local" formats, we can
just skip the adjustment and use localtime() instead of
gmtime(). This makes --date=format-local:%Z work correctly,
showing the local timezone instead of an empty string.
The new test checks the result for "UTC", our default
test-lib value for $TZ. Using something like EST5 might be
more interesting, but the actual zone string is
system-dependent (for instance, on my system it expands to
just EST). Hopefully "UTC" is vanilla enough that every
system treats it the same.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15 13:52:17 +00:00
|
|
|
strbuf_addftime(&timebuf, mode->strftime_fmt, tm, tz,
|
2017-07-01 13:15:47 +00:00
|
|
|
!mode->local);
|
2007-02-27 15:21:04 +00:00
|
|
|
else
|
2019-01-18 06:18:01 +00:00
|
|
|
show_date_normal(&timebuf, time, tm, tz, &human_tm, human_tz, mode->local);
|
2012-04-23 12:30:23 +00:00
|
|
|
return timebuf.buf;
|
2005-05-06 22:28:59 +00:00
|
|
|
}
|
|
|
|
|
2005-04-30 20:19:56 +00:00
|
|
|
/*
|
|
|
|
* Check these. And note how it doesn't do the summer-time conversion.
|
|
|
|
*
|
|
|
|
* In my world, it's always summer, and things are probably a bit off
|
|
|
|
* in other ways too.
|
|
|
|
*/
|
|
|
|
static const struct {
|
|
|
|
const char *name;
|
|
|
|
int offset;
|
2005-04-30 21:53:12 +00:00
|
|
|
int dst;
|
2005-04-30 20:19:56 +00:00
|
|
|
} timezone_names[] = {
|
2005-04-30 21:53:12 +00:00
|
|
|
{ "IDLW", -12, 0, }, /* International Date Line West */
|
|
|
|
{ "NT", -11, 0, }, /* Nome */
|
|
|
|
{ "CAT", -10, 0, }, /* Central Alaska */
|
|
|
|
{ "HST", -10, 0, }, /* Hawaii Standard */
|
|
|
|
{ "HDT", -10, 1, }, /* Hawaii Daylight */
|
|
|
|
{ "YST", -9, 0, }, /* Yukon Standard */
|
|
|
|
{ "YDT", -9, 1, }, /* Yukon Daylight */
|
|
|
|
{ "PST", -8, 0, }, /* Pacific Standard */
|
|
|
|
{ "PDT", -8, 1, }, /* Pacific Daylight */
|
|
|
|
{ "MST", -7, 0, }, /* Mountain Standard */
|
|
|
|
{ "MDT", -7, 1, }, /* Mountain Daylight */
|
|
|
|
{ "CST", -6, 0, }, /* Central Standard */
|
|
|
|
{ "CDT", -6, 1, }, /* Central Daylight */
|
|
|
|
{ "EST", -5, 0, }, /* Eastern Standard */
|
|
|
|
{ "EDT", -5, 1, }, /* Eastern Daylight */
|
|
|
|
{ "AST", -3, 0, }, /* Atlantic Standard */
|
|
|
|
{ "ADT", -3, 1, }, /* Atlantic Daylight */
|
|
|
|
{ "WAT", -1, 0, }, /* West Africa */
|
|
|
|
|
|
|
|
{ "GMT", 0, 0, }, /* Greenwich Mean */
|
|
|
|
{ "UTC", 0, 0, }, /* Universal (Coordinated) */
|
2010-05-17 19:07:10 +00:00
|
|
|
{ "Z", 0, 0, }, /* Zulu, alias for UTC */
|
2005-04-30 21:53:12 +00:00
|
|
|
|
|
|
|
{ "WET", 0, 0, }, /* Western European */
|
|
|
|
{ "BST", 0, 1, }, /* British Summer */
|
|
|
|
{ "CET", +1, 0, }, /* Central European */
|
|
|
|
{ "MET", +1, 0, }, /* Middle European */
|
|
|
|
{ "MEWT", +1, 0, }, /* Middle European Winter */
|
|
|
|
{ "MEST", +1, 1, }, /* Middle European Summer */
|
|
|
|
{ "CEST", +1, 1, }, /* Central European Summer */
|
|
|
|
{ "MESZ", +1, 1, }, /* Middle European Summer */
|
|
|
|
{ "FWT", +1, 0, }, /* French Winter */
|
|
|
|
{ "FST", +1, 1, }, /* French Summer */
|
|
|
|
{ "EET", +2, 0, }, /* Eastern Europe, USSR Zone 1 */
|
2005-04-30 22:21:57 +00:00
|
|
|
{ "EEST", +2, 1, }, /* Eastern European Daylight */
|
2005-04-30 21:53:12 +00:00
|
|
|
{ "WAST", +7, 0, }, /* West Australian Standard */
|
|
|
|
{ "WADT", +7, 1, }, /* West Australian Daylight */
|
|
|
|
{ "CCT", +8, 0, }, /* China Coast, USSR Zone 7 */
|
|
|
|
{ "JST", +9, 0, }, /* Japan Standard, USSR Zone 8 */
|
|
|
|
{ "EAST", +10, 0, }, /* Eastern Australian Standard */
|
|
|
|
{ "EADT", +10, 1, }, /* Eastern Australian Daylight */
|
|
|
|
{ "GST", +10, 0, }, /* Guam Standard, USSR Zone 9 */
|
2008-02-26 00:45:53 +00:00
|
|
|
{ "NZT", +12, 0, }, /* New Zealand */
|
|
|
|
{ "NZST", +12, 0, }, /* New Zealand Standard */
|
|
|
|
{ "NZDT", +12, 1, }, /* New Zealand Daylight */
|
2005-04-30 21:53:12 +00:00
|
|
|
{ "IDLE", +12, 0, }, /* International Date Line East */
|
2005-04-30 20:19:56 +00:00
|
|
|
};
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2005-04-30 20:19:56 +00:00
|
|
|
static int match_string(const char *date, const char *str)
|
2005-04-30 16:46:49 +00:00
|
|
|
{
|
2005-04-30 20:19:56 +00:00
|
|
|
int i = 0;
|
|
|
|
|
|
|
|
for (i = 0; *date; date++, str++, i++) {
|
|
|
|
if (*date == *str)
|
|
|
|
continue;
|
|
|
|
if (toupper(*date) == toupper(*str))
|
|
|
|
continue;
|
|
|
|
if (!isalnum(*date))
|
|
|
|
break;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return i;
|
2005-04-30 16:46:49 +00:00
|
|
|
}
|
|
|
|
|
2005-05-01 19:34:56 +00:00
|
|
|
static int skip_alpha(const char *date)
|
|
|
|
{
|
|
|
|
int i = 0;
|
|
|
|
do {
|
|
|
|
i++;
|
|
|
|
} while (isalpha(date[i]));
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
|
2005-04-30 20:19:56 +00:00
|
|
|
/*
|
|
|
|
* Parse month, weekday, or timezone name
|
|
|
|
*/
|
|
|
|
static int match_alpha(const char *date, struct tm *tm, int *offset)
|
2005-04-30 16:46:49 +00:00
|
|
|
{
|
2005-04-30 20:19:56 +00:00
|
|
|
int i;
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2005-04-30 20:19:56 +00:00
|
|
|
for (i = 0; i < 12; i++) {
|
|
|
|
int match = match_string(date, month_names[i]);
|
|
|
|
if (match >= 3) {
|
|
|
|
tm->tm_mon = i;
|
|
|
|
return match;
|
2005-04-30 16:46:49 +00:00
|
|
|
}
|
2005-04-30 20:19:56 +00:00
|
|
|
}
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2005-04-30 20:19:56 +00:00
|
|
|
for (i = 0; i < 7; i++) {
|
|
|
|
int match = match_string(date, weekday_names[i]);
|
|
|
|
if (match >= 3) {
|
|
|
|
tm->tm_wday = i;
|
|
|
|
return match;
|
|
|
|
}
|
|
|
|
}
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2006-03-09 19:58:05 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(timezone_names); i++) {
|
2005-04-30 20:19:56 +00:00
|
|
|
int match = match_string(date, timezone_names[i].name);
|
2010-05-17 19:07:10 +00:00
|
|
|
if (match >= 3 || match == strlen(timezone_names[i].name)) {
|
2005-04-30 21:53:12 +00:00
|
|
|
int off = timezone_names[i].offset;
|
|
|
|
|
|
|
|
/* This is bogus, but we like summer */
|
|
|
|
off += timezone_names[i].dst;
|
|
|
|
|
2005-04-30 22:21:57 +00:00
|
|
|
/* Only use the tz name offset if we don't have anything better */
|
|
|
|
if (*offset == -1)
|
|
|
|
*offset = 60*off;
|
|
|
|
|
2005-04-30 20:19:56 +00:00
|
|
|
return match;
|
2005-04-30 16:46:49 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-05-01 19:34:56 +00:00
|
|
|
if (match_string(date, "PM") == 2) {
|
2006-09-29 19:36:13 +00:00
|
|
|
tm->tm_hour = (tm->tm_hour % 12) + 12;
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (match_string(date, "AM") == 2) {
|
|
|
|
tm->tm_hour = (tm->tm_hour % 12) + 0;
|
2005-05-01 19:34:56 +00:00
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
2005-04-30 20:19:56 +00:00
|
|
|
/* BAD CRAP */
|
2005-05-01 19:34:56 +00:00
|
|
|
return skip_alpha(date);
|
2005-04-30 20:19:56 +00:00
|
|
|
}
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2006-04-05 22:31:12 +00:00
|
|
|
static int is_date(int year, int month, int day, struct tm *now_tm, time_t now, struct tm *tm)
|
2005-04-30 20:19:56 +00:00
|
|
|
{
|
2005-05-01 18:48:34 +00:00
|
|
|
if (month > 0 && month < 13 && day > 0 && day < 32) {
|
2006-04-05 22:31:12 +00:00
|
|
|
struct tm check = *tm;
|
|
|
|
struct tm *r = (now_tm ? &check : tm);
|
|
|
|
time_t specified;
|
|
|
|
|
|
|
|
r->tm_mon = month - 1;
|
|
|
|
r->tm_mday = day;
|
2005-05-01 18:48:34 +00:00
|
|
|
if (year == -1) {
|
2006-04-05 22:31:12 +00:00
|
|
|
if (!now_tm)
|
|
|
|
return 1;
|
|
|
|
r->tm_year = now_tm->tm_year;
|
2005-04-30 20:19:56 +00:00
|
|
|
}
|
2006-04-05 22:31:12 +00:00
|
|
|
else if (year >= 1970 && year < 2100)
|
|
|
|
r->tm_year = year - 1900;
|
|
|
|
else if (year > 70 && year < 100)
|
|
|
|
r->tm_year = year;
|
|
|
|
else if (year < 38)
|
|
|
|
r->tm_year = year + 100;
|
|
|
|
else
|
2005-05-01 18:48:34 +00:00
|
|
|
return 0;
|
2006-04-05 22:31:12 +00:00
|
|
|
if (!now_tm)
|
|
|
|
return 1;
|
|
|
|
|
2008-06-23 06:31:41 +00:00
|
|
|
specified = tm_to_time_t(r);
|
2005-05-01 18:48:34 +00:00
|
|
|
|
2006-04-05 22:31:12 +00:00
|
|
|
/* Be it commit time or author time, it does not make
|
|
|
|
* sense to specify timestamp way into the future. Make
|
|
|
|
* sure it is not later than ten days from now...
|
|
|
|
*/
|
2013-02-25 21:51:16 +00:00
|
|
|
if ((specified != -1) && (now + 10*24*3600 < specified))
|
2006-04-05 22:31:12 +00:00
|
|
|
return 0;
|
|
|
|
tm->tm_mon = r->tm_mon;
|
|
|
|
tm->tm_mday = r->tm_mday;
|
|
|
|
if (year != -1)
|
|
|
|
tm->tm_year = r->tm_year;
|
2005-05-01 18:48:34 +00:00
|
|
|
return 1;
|
2005-04-30 20:19:56 +00:00
|
|
|
}
|
2005-05-01 18:48:34 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
static int match_multi_number(timestamp_t num, char c, const char *date,
|
2014-11-13 11:04:52 +00:00
|
|
|
char *end, struct tm *tm, time_t now)
|
2005-05-01 18:48:34 +00:00
|
|
|
{
|
2006-04-05 22:31:12 +00:00
|
|
|
struct tm now_tm;
|
|
|
|
struct tm *refuse_future;
|
2005-05-01 18:48:34 +00:00
|
|
|
long num2, num3;
|
|
|
|
|
|
|
|
num2 = strtol(end+1, &end, 10);
|
|
|
|
num3 = -1;
|
|
|
|
if (*end == c && isdigit(end[1]))
|
|
|
|
num3 = strtol(end+1, &end, 10);
|
|
|
|
|
|
|
|
/* Time? Date? */
|
2005-04-30 20:19:56 +00:00
|
|
|
switch (c) {
|
2005-05-01 18:48:34 +00:00
|
|
|
case ':':
|
|
|
|
if (num3 < 0)
|
|
|
|
num3 = 0;
|
|
|
|
if (num < 25 && num2 >= 0 && num2 < 60 && num3 >= 0 && num3 <= 60) {
|
|
|
|
tm->tm_hour = num;
|
|
|
|
tm->tm_min = num2;
|
|
|
|
tm->tm_sec = num3;
|
2005-04-30 20:19:56 +00:00
|
|
|
break;
|
|
|
|
}
|
2005-05-01 18:48:34 +00:00
|
|
|
return 0;
|
2005-04-30 20:19:56 +00:00
|
|
|
|
|
|
|
case '-':
|
|
|
|
case '/':
|
2006-04-05 22:31:12 +00:00
|
|
|
case '.':
|
2014-11-13 11:04:52 +00:00
|
|
|
if (!now)
|
|
|
|
now = time(NULL);
|
2006-04-05 22:31:12 +00:00
|
|
|
refuse_future = NULL;
|
|
|
|
if (gmtime_r(&now, &now_tm))
|
|
|
|
refuse_future = &now_tm;
|
|
|
|
|
2005-05-01 18:48:34 +00:00
|
|
|
if (num > 70) {
|
|
|
|
/* yyyy-mm-dd? */
|
approxidate: allow ISO-like dates far in the future
When we are parsing approxidate strings and we find three
numbers separate by one of ":/-.", we guess that it may be a
date. We feed the numbers to match_multi_number, which
checks whether it makes sense as a date in various orderings
(e.g., dd/mm/yy or mm/dd/yy, etc).
One of the checks we do is to see whether it is a date more
than 10 days in the future. This was added in 38035cf (date
parsing: be friendlier to our European friends.,
2006-04-05), and lets us guess that if it is currently April
2014, then "10/03/2014" is probably March 10th, not October
3rd.
This has a downside, though; if you want to be overly
generous with your "--until" date specification, we may
wrongly parse "2014-12-01" as "2014-01-12" (because the
latter is an in-the-past date). If the year is a future year
(i.e., both are future dates), it gets even weirder. Due to
the vagaries of approxidate, months _after_ the current date
(no matter the year) get flipped, but ones before do not.
This patch drops the "in the future" check for dates of this
form, letting us treat them always as yyyy-mm-dd, even if
they are in the future. This does not affect the normal
dd/mm/yyyy versus mm/dd/yyyy lookup, because this code path
only kicks in when the first number is greater than 70
(i.e., it must be a year, and cannot be either a date or a
month).
The one possible casualty is that "yyyy-dd-mm" is less
likely to be chosen over "yyyy-mm-dd". That's probably OK,
though because:
1. The difference happens only when the date is in the
future. Already we prefer yyyy-mm-dd for dates in the
past.
2. It's unclear whether anybody even uses yyyy-dd-mm
regularly. It does not appear in lists of common date
formats in Wikipedia[1,2].
3. Even if (2) is wrong, it is better to prefer ISO-like
dates, as that is consistent with what we use elsewhere
in git.
[1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country
[2] http://en.wikipedia.org/wiki/Calendar_date
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-13 21:43:31 +00:00
|
|
|
if (is_date(num, num2, num3, NULL, now, tm))
|
2005-05-01 18:48:34 +00:00
|
|
|
break;
|
|
|
|
/* yyyy-dd-mm? */
|
approxidate: allow ISO-like dates far in the future
When we are parsing approxidate strings and we find three
numbers separate by one of ":/-.", we guess that it may be a
date. We feed the numbers to match_multi_number, which
checks whether it makes sense as a date in various orderings
(e.g., dd/mm/yy or mm/dd/yy, etc).
One of the checks we do is to see whether it is a date more
than 10 days in the future. This was added in 38035cf (date
parsing: be friendlier to our European friends.,
2006-04-05), and lets us guess that if it is currently April
2014, then "10/03/2014" is probably March 10th, not October
3rd.
This has a downside, though; if you want to be overly
generous with your "--until" date specification, we may
wrongly parse "2014-12-01" as "2014-01-12" (because the
latter is an in-the-past date). If the year is a future year
(i.e., both are future dates), it gets even weirder. Due to
the vagaries of approxidate, months _after_ the current date
(no matter the year) get flipped, but ones before do not.
This patch drops the "in the future" check for dates of this
form, letting us treat them always as yyyy-mm-dd, even if
they are in the future. This does not affect the normal
dd/mm/yyyy versus mm/dd/yyyy lookup, because this code path
only kicks in when the first number is greater than 70
(i.e., it must be a year, and cannot be either a date or a
month).
The one possible casualty is that "yyyy-dd-mm" is less
likely to be chosen over "yyyy-mm-dd". That's probably OK,
though because:
1. The difference happens only when the date is in the
future. Already we prefer yyyy-mm-dd for dates in the
past.
2. It's unclear whether anybody even uses yyyy-dd-mm
regularly. It does not appear in lists of common date
formats in Wikipedia[1,2].
3. Even if (2) is wrong, it is better to prefer ISO-like
dates, as that is consistent with what we use elsewhere
in git.
[1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country
[2] http://en.wikipedia.org/wiki/Calendar_date
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-13 21:43:31 +00:00
|
|
|
if (is_date(num, num3, num2, NULL, now, tm))
|
2005-04-30 20:19:56 +00:00
|
|
|
break;
|
2005-05-01 18:48:34 +00:00
|
|
|
}
|
2006-04-05 22:31:12 +00:00
|
|
|
/* Our eastern European friends say dd.mm.yy[yy]
|
|
|
|
* is the norm there, so giving precedence to
|
|
|
|
* mm/dd/yy[yy] form only when separator is not '.'
|
|
|
|
*/
|
|
|
|
if (c != '.' &&
|
|
|
|
is_date(num3, num, num2, refuse_future, now, tm))
|
|
|
|
break;
|
|
|
|
/* European dd.mm.yy[yy] or funny US dd/mm/yy[yy] */
|
|
|
|
if (is_date(num3, num2, num, refuse_future, now, tm))
|
2005-04-30 20:19:56 +00:00
|
|
|
break;
|
2006-04-05 22:31:12 +00:00
|
|
|
/* Funny European mm.dd.yy */
|
|
|
|
if (c == '.' &&
|
|
|
|
is_date(num3, num, num2, refuse_future, now, tm))
|
2005-05-01 18:48:34 +00:00
|
|
|
break;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return end - date;
|
|
|
|
}
|
|
|
|
|
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-23 01:11:44 +00:00
|
|
|
/*
|
|
|
|
* Have we filled in any part of the time/date yet?
|
|
|
|
* We just do a binary 'and' to see if the sign bit
|
|
|
|
* is set in all the values.
|
|
|
|
*/
|
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 04:25:40 +00:00
|
|
|
static inline int nodate(struct tm *tm)
|
|
|
|
{
|
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-23 01:11:44 +00:00
|
|
|
return (tm->tm_year &
|
|
|
|
tm->tm_mon &
|
|
|
|
tm->tm_mday &
|
|
|
|
tm->tm_hour &
|
|
|
|
tm->tm_min &
|
|
|
|
tm->tm_sec) < 0;
|
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 04:25:40 +00:00
|
|
|
}
|
|
|
|
|
2005-05-01 18:48:34 +00:00
|
|
|
/*
|
2007-06-07 07:04:01 +00:00
|
|
|
* We've seen a digit. Time? Year? Date?
|
2005-05-01 18:48:34 +00:00
|
|
|
*/
|
2005-07-12 17:33:06 +00:00
|
|
|
static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt)
|
2005-05-01 18:48:34 +00:00
|
|
|
{
|
|
|
|
int n;
|
|
|
|
char *end;
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t num;
|
2005-05-01 18:48:34 +00:00
|
|
|
|
2017-04-21 10:45:44 +00:00
|
|
|
num = parse_timestamp(date, &end, 10);
|
2005-05-01 18:48:34 +00:00
|
|
|
|
|
|
|
/*
|
2007-06-06 08:11:55 +00:00
|
|
|
* Seconds since 1970? We trigger on that for any numbers with
|
|
|
|
* more than 8 digits. This is because we don't want to rule out
|
|
|
|
* numbers like 20070606 as a YYYYMMDD date.
|
2005-05-01 18:48:34 +00:00
|
|
|
*/
|
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 04:25:40 +00:00
|
|
|
if (num >= 100000000 && nodate(tm)) {
|
2005-05-01 18:48:34 +00:00
|
|
|
time_t time = num;
|
2005-06-25 09:21:16 +00:00
|
|
|
if (gmtime_r(&time, tm)) {
|
|
|
|
*tm_gmt = 1;
|
2005-05-01 18:48:34 +00:00
|
|
|
return end - date;
|
2005-06-25 09:21:16 +00:00
|
|
|
}
|
2005-05-01 18:48:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2006-04-05 22:31:12 +00:00
|
|
|
* Check for special formats: num[-.:/]num[same]num
|
2005-05-01 18:48:34 +00:00
|
|
|
*/
|
|
|
|
switch (*end) {
|
|
|
|
case ':':
|
2006-04-05 22:31:12 +00:00
|
|
|
case '.':
|
2005-05-01 18:48:34 +00:00
|
|
|
case '/':
|
|
|
|
case '-':
|
|
|
|
if (isdigit(end[1])) {
|
2014-11-13 11:04:52 +00:00
|
|
|
int match = match_multi_number(num, *end, date, end, tm, 0);
|
2005-05-01 18:48:34 +00:00
|
|
|
if (match)
|
|
|
|
return match;
|
2005-04-30 20:19:56 +00:00
|
|
|
}
|
|
|
|
}
|
2005-05-01 18:48:34 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* None of the special formats? Try to guess what
|
|
|
|
* the number meant. We use the number of digits
|
|
|
|
* to make a more educated guess..
|
|
|
|
*/
|
|
|
|
n = 0;
|
|
|
|
do {
|
|
|
|
n++;
|
|
|
|
} while (isdigit(date[n]));
|
|
|
|
|
|
|
|
/* Four-digit year or a timezone? */
|
|
|
|
if (n == 4) {
|
2006-06-08 21:54:13 +00:00
|
|
|
if (num <= 1400 && *offset == -1) {
|
2005-05-01 18:48:34 +00:00
|
|
|
unsigned int minutes = num % 100;
|
|
|
|
unsigned int hours = num / 100;
|
|
|
|
*offset = hours*60 + minutes;
|
|
|
|
} else if (num > 1900 && num < 2100)
|
|
|
|
tm->tm_year = num - 1900;
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
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 04:25:40 +00:00
|
|
|
/*
|
|
|
|
* Ignore lots of numerals. We took care of 4-digit years above.
|
|
|
|
* Days or months must be one or two digits.
|
|
|
|
*/
|
|
|
|
if (n > 2)
|
|
|
|
return n;
|
|
|
|
|
2005-05-01 18:48:34 +00:00
|
|
|
/*
|
|
|
|
* NOTE! We will give precedence to day-of-month over month or
|
2005-12-29 09:30:08 +00:00
|
|
|
* year numbers in the 1-12 range. So 05 is always "mday 5",
|
2005-05-01 18:48:34 +00:00
|
|
|
* unless we already have a mday..
|
|
|
|
*
|
|
|
|
* IOW, 01 Apr 05 parses as "April 1st, 2005".
|
|
|
|
*/
|
|
|
|
if (num > 0 && num < 32 && tm->tm_mday < 0) {
|
|
|
|
tm->tm_mday = num;
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Two-digit year? */
|
|
|
|
if (n == 2 && tm->tm_year < 0) {
|
|
|
|
if (num < 10 && tm->tm_mday >= 0) {
|
|
|
|
tm->tm_year = num + 100;
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
if (num >= 70) {
|
|
|
|
tm->tm_year = num;
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
if (num > 0 && num < 13 && tm->tm_mon < 0)
|
2005-05-01 18:48:34 +00:00
|
|
|
tm->tm_mon = num-1;
|
2007-06-07 07:04:01 +00:00
|
|
|
|
2005-05-01 18:48:34 +00:00
|
|
|
return n;
|
2005-04-30 20:19:56 +00:00
|
|
|
}
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2005-07-12 17:33:06 +00:00
|
|
|
static int match_tz(const char *date, int *offp)
|
2005-04-30 20:19:56 +00:00
|
|
|
{
|
|
|
|
char *end;
|
2011-09-09 10:10:33 +00:00
|
|
|
int hour = strtoul(date + 1, &end, 10);
|
|
|
|
int n = end - (date + 1);
|
|
|
|
int min = 0;
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2011-09-09 10:10:33 +00:00
|
|
|
if (n == 4) {
|
|
|
|
/* hhmm */
|
|
|
|
min = hour % 100;
|
|
|
|
hour = hour / 100;
|
|
|
|
} else if (n != 2) {
|
|
|
|
min = 99; /* random crap */
|
|
|
|
} else if (*end == ':') {
|
|
|
|
/* hh:mm? */
|
|
|
|
min = strtoul(end + 1, &end, 10);
|
|
|
|
if (end - (date + 1) != 5)
|
|
|
|
min = 99; /* random crap */
|
|
|
|
} /* otherwise we parsed "hh" */
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2005-05-01 18:48:34 +00:00
|
|
|
/*
|
2011-09-09 10:10:33 +00:00
|
|
|
* Don't accept any random crap. Even though some places have
|
|
|
|
* offset larger than 12 hours (e.g. Pacific/Kiritimati is at
|
|
|
|
* UTC+14), there is something wrong if hour part is much
|
|
|
|
* larger than that. We might also want to check that the
|
|
|
|
* minutes are divisible by 15 or something too. (Offset of
|
|
|
|
* Kathmandu, Nepal is UTC+5:45)
|
2005-05-01 18:48:34 +00:00
|
|
|
*/
|
2011-09-09 10:10:33 +00:00
|
|
|
if (min < 60 && hour < 24) {
|
|
|
|
int offset = hour * 60 + min;
|
2005-05-01 19:34:56 +00:00
|
|
|
if (*date == '-')
|
|
|
|
offset = -offset;
|
|
|
|
*offp = offset;
|
|
|
|
}
|
2005-04-30 20:19:56 +00:00
|
|
|
return end - date;
|
|
|
|
}
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
static void date_string(timestamp_t date, int offset, struct strbuf *buf)
|
2005-09-21 22:50:28 +00:00
|
|
|
{
|
|
|
|
int sign = '+';
|
|
|
|
|
|
|
|
if (offset < 0) {
|
|
|
|
offset = -offset;
|
|
|
|
sign = '-';
|
|
|
|
}
|
2017-04-21 10:45:48 +00:00
|
|
|
strbuf_addf(buf, "%"PRItime" %c%02d%02d", date, sign, offset / 60, offset % 60);
|
2005-09-21 22:50:28 +00:00
|
|
|
}
|
|
|
|
|
2012-02-02 21:41:42 +00:00
|
|
|
/*
|
|
|
|
* Parse a string like "0 +0000" as ancient timestamp near epoch, but
|
|
|
|
* only when it appears not as part of any other string.
|
|
|
|
*/
|
2017-04-26 19:29:31 +00:00
|
|
|
static int match_object_header_date(const char *date, timestamp_t *timestamp, int *offset)
|
2012-02-02 21:41:42 +00:00
|
|
|
{
|
|
|
|
char *end;
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t stamp;
|
2012-02-02 21:41:42 +00:00
|
|
|
int ofs;
|
|
|
|
|
2012-07-12 20:46:49 +00:00
|
|
|
if (*date < '0' || '9' < *date)
|
2012-02-02 21:41:42 +00:00
|
|
|
return -1;
|
2017-04-21 10:45:44 +00:00
|
|
|
stamp = parse_timestamp(date, &end, 10);
|
2017-04-26 19:29:31 +00:00
|
|
|
if (*end != ' ' || stamp == TIME_MAX || (end[1] != '+' && end[1] != '-'))
|
2012-02-02 21:41:42 +00:00
|
|
|
return -1;
|
|
|
|
date = end + 2;
|
|
|
|
ofs = strtol(date, &end, 10);
|
|
|
|
if ((*end != '\0' && (*end != '\n')) || end != date + 4)
|
|
|
|
return -1;
|
|
|
|
ofs = (ofs / 100) * 60 + (ofs % 100);
|
|
|
|
if (date[-1] == '-')
|
|
|
|
ofs = -ofs;
|
|
|
|
*timestamp = stamp;
|
|
|
|
*offset = ofs;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-30 20:19:56 +00:00
|
|
|
/* Gr. strptime is crap for this; it doesn't have a way to require RFC2822
|
|
|
|
(i.e. English) day/month names, and it doesn't work correctly with %z. */
|
2017-04-26 19:29:31 +00:00
|
|
|
int parse_date_basic(const char *date, timestamp_t *timestamp, int *offset)
|
2005-04-30 20:19:56 +00:00
|
|
|
{
|
|
|
|
struct tm tm;
|
2010-06-03 20:28:55 +00:00
|
|
|
int tm_gmt;
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t dummy_timestamp;
|
2010-06-03 20:28:55 +00:00
|
|
|
int dummy_offset;
|
|
|
|
|
|
|
|
if (!timestamp)
|
|
|
|
timestamp = &dummy_timestamp;
|
|
|
|
if (!offset)
|
|
|
|
offset = &dummy_offset;
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2005-04-30 20:19:56 +00:00
|
|
|
memset(&tm, 0, sizeof(tm));
|
|
|
|
tm.tm_year = -1;
|
|
|
|
tm.tm_mon = -1;
|
|
|
|
tm.tm_mday = -1;
|
2005-04-30 21:25:02 +00:00
|
|
|
tm.tm_isdst = -1;
|
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-23 01:11:44 +00:00
|
|
|
tm.tm_hour = -1;
|
|
|
|
tm.tm_min = -1;
|
|
|
|
tm.tm_sec = -1;
|
2010-06-03 20:28:55 +00:00
|
|
|
*offset = -1;
|
2005-06-25 09:21:16 +00:00
|
|
|
tm_gmt = 0;
|
2005-04-30 20:19:56 +00:00
|
|
|
|
2012-02-02 21:41:43 +00:00
|
|
|
if (*date == '@' &&
|
|
|
|
!match_object_header_date(date + 1, timestamp, offset))
|
2012-02-02 21:41:42 +00:00
|
|
|
return 0; /* success */
|
2005-04-30 20:19:56 +00:00
|
|
|
for (;;) {
|
|
|
|
int match = 0;
|
|
|
|
unsigned char c = *date;
|
|
|
|
|
|
|
|
/* Stop at end of string or newline */
|
|
|
|
if (!c || c == '\n')
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (isalpha(c))
|
2010-06-03 20:28:55 +00:00
|
|
|
match = match_alpha(date, &tm, offset);
|
2005-04-30 20:19:56 +00:00
|
|
|
else if (isdigit(c))
|
2010-06-03 20:28:55 +00:00
|
|
|
match = match_digit(date, &tm, offset, &tm_gmt);
|
2005-04-30 20:19:56 +00:00
|
|
|
else if ((c == '-' || c == '+') && isdigit(date[1]))
|
2010-06-03 20:28:55 +00:00
|
|
|
match = match_tz(date, offset);
|
2005-04-30 20:19:56 +00:00
|
|
|
|
|
|
|
if (!match) {
|
|
|
|
/* BAD CRAP */
|
|
|
|
match = 1;
|
2007-06-07 07:04:01 +00:00
|
|
|
}
|
2005-04-30 20:19:56 +00:00
|
|
|
|
|
|
|
date += match;
|
|
|
|
}
|
2005-04-30 16:46:49 +00:00
|
|
|
|
2015-04-15 15:47:48 +00:00
|
|
|
/* do not use mktime(), which uses local timezone, here */
|
2010-06-03 20:28:55 +00:00
|
|
|
*timestamp = tm_to_time_t(&tm);
|
2015-04-15 15:43:58 +00:00
|
|
|
if (*timestamp == -1)
|
|
|
|
return -1;
|
|
|
|
|
2013-02-25 21:53:40 +00:00
|
|
|
if (*offset == -1) {
|
2015-04-15 15:47:48 +00:00
|
|
|
time_t temp_time;
|
|
|
|
|
|
|
|
/* gmtime_r() in match_digit() may have clobbered it */
|
|
|
|
tm.tm_isdst = -1;
|
|
|
|
temp_time = mktime(&tm);
|
2013-02-25 21:53:40 +00:00
|
|
|
if ((time_t)*timestamp > temp_time) {
|
|
|
|
*offset = ((time_t)*timestamp - temp_time) / 60;
|
|
|
|
} else {
|
|
|
|
*offset = -(int)((temp_time - (time_t)*timestamp) / 60);
|
|
|
|
}
|
|
|
|
}
|
2005-04-30 21:25:02 +00:00
|
|
|
|
2005-06-25 09:21:16 +00:00
|
|
|
if (!tm_gmt)
|
2010-06-03 20:28:55 +00:00
|
|
|
*timestamp -= *offset * 60;
|
2010-07-15 16:22:57 +00:00
|
|
|
return 0; /* success */
|
2010-06-03 20:28:55 +00:00
|
|
|
}
|
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
int parse_expiry_date(const char *date, timestamp_t *timestamp)
|
2013-04-17 22:38:08 +00:00
|
|
|
{
|
|
|
|
int errors = 0;
|
|
|
|
|
|
|
|
if (!strcmp(date, "never") || !strcmp(date, "false"))
|
|
|
|
*timestamp = 0;
|
|
|
|
else if (!strcmp(date, "all") || !strcmp(date, "now"))
|
|
|
|
/*
|
|
|
|
* We take over "now" here, which usually translates
|
|
|
|
* to the current timestamp. This is because the user
|
|
|
|
* really means to expire everything she has done in
|
|
|
|
* the past, and by definition reflogs are the record
|
|
|
|
* of the past, and there is nothing from the future
|
|
|
|
* to be kept.
|
|
|
|
*/
|
2017-04-26 19:29:31 +00:00
|
|
|
*timestamp = TIME_MAX;
|
2013-04-17 22:38:08 +00:00
|
|
|
else
|
|
|
|
*timestamp = approxidate_careful(date, &errors);
|
|
|
|
|
|
|
|
return errors;
|
|
|
|
}
|
|
|
|
|
2014-08-27 07:57:08 +00:00
|
|
|
int parse_date(const char *date, struct strbuf *result)
|
2010-06-03 20:28:55 +00:00
|
|
|
{
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t timestamp;
|
2010-06-03 20:28:55 +00:00
|
|
|
int offset;
|
2010-07-15 16:22:57 +00:00
|
|
|
if (parse_date_basic(date, ×tamp, &offset))
|
2010-06-03 20:28:55 +00:00
|
|
|
return -1;
|
2014-08-27 07:57:08 +00:00
|
|
|
date_string(timestamp, offset, result);
|
|
|
|
return 0;
|
2005-04-30 16:46:49 +00:00
|
|
|
}
|
|
|
|
|
2015-09-03 21:48:59 +00:00
|
|
|
static enum date_mode_type parse_date_type(const char *format, const char **end)
|
|
|
|
{
|
|
|
|
if (skip_prefix(format, "relative", end))
|
|
|
|
return DATE_RELATIVE;
|
|
|
|
if (skip_prefix(format, "iso8601-strict", end) ||
|
|
|
|
skip_prefix(format, "iso-strict", end))
|
|
|
|
return DATE_ISO8601_STRICT;
|
|
|
|
if (skip_prefix(format, "iso8601", end) ||
|
|
|
|
skip_prefix(format, "iso", end))
|
|
|
|
return DATE_ISO8601;
|
|
|
|
if (skip_prefix(format, "rfc2822", end) ||
|
|
|
|
skip_prefix(format, "rfc", end))
|
|
|
|
return DATE_RFC2822;
|
|
|
|
if (skip_prefix(format, "short", end))
|
|
|
|
return DATE_SHORT;
|
|
|
|
if (skip_prefix(format, "default", end))
|
|
|
|
return DATE_NORMAL;
|
2019-01-18 06:18:01 +00:00
|
|
|
if (skip_prefix(format, "human", end))
|
|
|
|
return DATE_HUMAN;
|
2015-09-03 21:48:59 +00:00
|
|
|
if (skip_prefix(format, "raw", end))
|
|
|
|
return DATE_RAW;
|
2016-07-22 19:51:49 +00:00
|
|
|
if (skip_prefix(format, "unix", end))
|
|
|
|
return DATE_UNIX;
|
2015-09-03 21:48:59 +00:00
|
|
|
if (skip_prefix(format, "format", end))
|
|
|
|
return DATE_STRFTIME;
|
2019-02-16 11:24:41 +00:00
|
|
|
/*
|
|
|
|
* Please update $__git_log_date_formats in
|
|
|
|
* git-completion.bash when you add new formats.
|
|
|
|
*/
|
2015-09-03 21:48:59 +00:00
|
|
|
|
|
|
|
die("unknown date format %s", format);
|
|
|
|
}
|
|
|
|
|
convert "enum date_mode" into a struct
In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.
Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor. However, the tricky case is where we use the
enum labels as constants, like:
show_date(t, tz, DATE_NORMAL);
Ideally we could say:
show_date(t, tz, &{ DATE_NORMAL });
but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:
1. Manually add a "struct date_mode d = { DATE_NORMAL }"
definition to each caller, and pass "&d". This makes
the callers uglier, because they sometimes do not even
have their own scope (e.g., they are inside a switch
statement).
2. Provide a pre-made global "date_normal" struct that can
be passed by address. We'd also need "date_rfc2822",
"date_iso8601", and so forth. But at least the ugliness
is defined in one place.
3. Provide a wrapper that generates the correct struct on
the fly. The big downside is that we end up pointing to
a single global, which makes our wrapper non-reentrant.
But show_date is already not reentrant, so it does not
matter.
This patch implements 3, along with a minor macro to keep
the size of the callers sane.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-25 16:55:02 +00:00
|
|
|
void parse_date_format(const char *format, struct date_mode *mode)
|
2007-09-28 14:17:31 +00:00
|
|
|
{
|
2015-09-03 21:48:59 +00:00
|
|
|
const char *p;
|
|
|
|
|
2019-01-21 05:31:09 +00:00
|
|
|
/* "auto:foo" is "if tty/pager, then foo, otherwise normal" */
|
|
|
|
if (skip_prefix(format, "auto:", &p)) {
|
|
|
|
if (isatty(1) || pager_in_use())
|
|
|
|
format = p;
|
|
|
|
else
|
|
|
|
format = "default";
|
|
|
|
}
|
|
|
|
|
2015-09-03 21:48:59 +00:00
|
|
|
/* historical alias */
|
|
|
|
if (!strcmp(format, "local"))
|
|
|
|
format = "default-local";
|
|
|
|
|
|
|
|
mode->type = parse_date_type(format, &p);
|
|
|
|
mode->local = 0;
|
|
|
|
|
|
|
|
if (skip_prefix(p, "-local", &p))
|
|
|
|
mode->local = 1;
|
|
|
|
|
|
|
|
if (mode->type == DATE_STRFTIME) {
|
|
|
|
if (!skip_prefix(p, ":", &p))
|
|
|
|
die("date format missing colon separator: %s", format);
|
|
|
|
mode->strftime_fmt = xstrdup(p);
|
|
|
|
} else if (*p)
|
2007-09-28 14:17:31 +00:00
|
|
|
die("unknown date format %s", format);
|
|
|
|
}
|
|
|
|
|
2014-08-27 07:57:08 +00:00
|
|
|
void datestamp(struct strbuf *out)
|
2005-04-30 16:46:49 +00:00
|
|
|
{
|
|
|
|
time_t now;
|
|
|
|
int offset;
|
2019-11-28 12:25:03 +00:00
|
|
|
struct tm tm = { 0 };
|
2005-04-30 16:46:49 +00:00
|
|
|
|
|
|
|
time(&now);
|
|
|
|
|
2019-11-28 12:25:03 +00:00
|
|
|
offset = tm_to_time_t(localtime_r(&now, &tm)) - now;
|
2005-04-30 16:46:49 +00:00
|
|
|
offset /= 60;
|
|
|
|
|
2014-08-27 07:57:08 +00:00
|
|
|
date_string(now, offset, out);
|
2005-04-30 16:46:49 +00:00
|
|
|
}
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
/*
|
|
|
|
* Relative time update (eg "2 days ago"). If we haven't set the time
|
|
|
|
* yet, we need to set it from current time.
|
|
|
|
*/
|
2017-04-26 19:29:31 +00:00
|
|
|
static time_t update_tm(struct tm *tm, struct tm *now, time_t sec)
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
{
|
2009-08-22 22:10:07 +00:00
|
|
|
time_t n;
|
|
|
|
|
|
|
|
if (tm->tm_mday < 0)
|
|
|
|
tm->tm_mday = now->tm_mday;
|
|
|
|
if (tm->tm_mon < 0)
|
|
|
|
tm->tm_mon = now->tm_mon;
|
|
|
|
if (tm->tm_year < 0) {
|
|
|
|
tm->tm_year = now->tm_year;
|
|
|
|
if (tm->tm_mon > now->tm_mon)
|
|
|
|
tm->tm_year--;
|
|
|
|
}
|
|
|
|
|
|
|
|
n = mktime(tm) - sec;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
localtime_r(&n, tm);
|
2009-08-22 22:10:07 +00:00
|
|
|
return n;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
}
|
|
|
|
|
approxidate: handle pending number for "specials"
The approxidate parser has a table of special keywords like
"yesterday", "noon", "pm", etc. Some of these, like "pm", do
the right thing if we've recently seen a number: "3pm" is
what you'd think.
However, most of them do not look at or modify the
pending-number flag at all, which means a number may "jump"
across a significant keyword and be used unexpectedly. For
example, when parsing:
January 5th noon pm
we'd connect the "5" to "pm", and ignore it as a
day-of-month. This is obviously a bit silly, as "noon"
already implies "pm". And other mis-parsed things are
generally as silly ("January 5th noon, years ago" would
connect the 5 to "years", but probably nobody would type
that).
However, the fix is simple: when we see a keyword like
"noon", we should flush the pending number (as we would if
we hit another number, or the end of the string). In a few
of the specials that actually modify the day, we can simply
throw away the number (saying "Jan 5 yesterday" should not
respect the number at all).
Note that we have to either move or forward-declare the
static pending_number() to make it accessible to these
functions; this patch moves it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02 05:23:09 +00:00
|
|
|
/*
|
|
|
|
* Do we have a pending number at the end, or when
|
|
|
|
* we see a new one? Let's assume it's a month day,
|
|
|
|
* as in "Dec 6, 1992"
|
|
|
|
*/
|
|
|
|
static void pending_number(struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
int number = *num;
|
|
|
|
|
|
|
|
if (number) {
|
|
|
|
*num = 0;
|
|
|
|
if (tm->tm_mday < 0 && number < 32)
|
|
|
|
tm->tm_mday = number;
|
|
|
|
else if (tm->tm_mon < 0 && number < 13)
|
|
|
|
tm->tm_mon = number-1;
|
|
|
|
else if (tm->tm_year < 0) {
|
|
|
|
if (number > 1969 && number < 2100)
|
|
|
|
tm->tm_year = number - 1900;
|
|
|
|
else if (number > 69 && number < 100)
|
|
|
|
tm->tm_year = number;
|
|
|
|
else if (number < 38)
|
|
|
|
tm->tm_year = 100 + number;
|
|
|
|
/* We screw up for number = 00 ? */
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-01-26 19:58:00 +00:00
|
|
|
static void date_now(struct tm *tm, struct tm *now, int *num)
|
|
|
|
{
|
approxidate: handle pending number for "specials"
The approxidate parser has a table of special keywords like
"yesterday", "noon", "pm", etc. Some of these, like "pm", do
the right thing if we've recently seen a number: "3pm" is
what you'd think.
However, most of them do not look at or modify the
pending-number flag at all, which means a number may "jump"
across a significant keyword and be used unexpectedly. For
example, when parsing:
January 5th noon pm
we'd connect the "5" to "pm", and ignore it as a
day-of-month. This is obviously a bit silly, as "noon"
already implies "pm". And other mis-parsed things are
generally as silly ("January 5th noon, years ago" would
connect the 5 to "years", but probably nobody would type
that).
However, the fix is simple: when we see a keyword like
"noon", we should flush the pending number (as we would if
we hit another number, or the end of the string). In a few
of the specials that actually modify the day, we can simply
throw away the number (saying "Jan 5 yesterday" should not
respect the number at all).
Note that we have to either move or forward-declare the
static pending_number() to make it accessible to these
functions; this patch moves it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02 05:23:09 +00:00
|
|
|
*num = 0;
|
2010-01-26 19:58:00 +00:00
|
|
|
update_tm(tm, now, 0);
|
|
|
|
}
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
static void date_yesterday(struct tm *tm, struct tm *now, int *num)
|
2005-11-18 16:56:40 +00:00
|
|
|
{
|
approxidate: handle pending number for "specials"
The approxidate parser has a table of special keywords like
"yesterday", "noon", "pm", etc. Some of these, like "pm", do
the right thing if we've recently seen a number: "3pm" is
what you'd think.
However, most of them do not look at or modify the
pending-number flag at all, which means a number may "jump"
across a significant keyword and be used unexpectedly. For
example, when parsing:
January 5th noon pm
we'd connect the "5" to "pm", and ignore it as a
day-of-month. This is obviously a bit silly, as "noon"
already implies "pm". And other mis-parsed things are
generally as silly ("January 5th noon, years ago" would
connect the 5 to "years", but probably nobody would type
that).
However, the fix is simple: when we see a keyword like
"noon", we should flush the pending number (as we would if
we hit another number, or the end of the string). In a few
of the specials that actually modify the day, we can simply
throw away the number (saying "Jan 5 yesterday" should not
respect the number at all).
Note that we have to either move or forward-declare the
static pending_number() to make it accessible to these
functions; this patch moves it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02 05:23:09 +00:00
|
|
|
*num = 0;
|
2009-08-22 22:10:07 +00:00
|
|
|
update_tm(tm, now, 24*60*60);
|
2005-11-18 16:56:40 +00:00
|
|
|
}
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
static void date_time(struct tm *tm, struct tm *now, int hour)
|
2005-11-18 16:56:40 +00:00
|
|
|
{
|
|
|
|
if (tm->tm_hour < hour)
|
approxidate: fix NULL dereference in date_time()
When we see a time like "noon", we pass "12" to our date_time() helper,
which sets the hour to 12pm. If the current time is before noon, then we
wrap around to yesterday using date_yesterday(). But unlike the normal
calls to date_yesterday() from approxidate_alpha(), we pass a NULL "num"
parameter. Since c27cc94fad (approxidate: handle pending number for
"specials", 2018-11-02), that causes a segfault.
One way to fix this is by checking for NULL. But arguably date_time() is
abusing our helper by passing NULL in the first place (and this is the
only case where one of these "special" parsers is used this way). So
instead, let's have it just do the 1-day subtraction itself. It's still
just a one-liner due to our update_tm() helper.
Note that the test added here is a little funny, as we say "10am noon",
which makes the "10am" seem pointless. But this bug can only be
triggered when it the currently-parsed hour is before the special time.
The latest special time is "tea" at 1700, but t0006 uses a hard-coded
TEST_DATE_NOW of 1900. We could reset TEST_DATE_NOW, but that may lead
to confusion in other tests. Just saying "10am noon" makes this test
self-contained.
Reported-by: Carlo Arenas <carenas@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-07 01:12:53 +00:00
|
|
|
update_tm(tm, now, 24*60*60);
|
2005-11-18 16:56:40 +00:00
|
|
|
tm->tm_hour = hour;
|
|
|
|
tm->tm_min = 0;
|
|
|
|
tm->tm_sec = 0;
|
|
|
|
}
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
static void date_midnight(struct tm *tm, struct tm *now, int *num)
|
2005-11-18 16:56:40 +00:00
|
|
|
{
|
approxidate: handle pending number for "specials"
The approxidate parser has a table of special keywords like
"yesterday", "noon", "pm", etc. Some of these, like "pm", do
the right thing if we've recently seen a number: "3pm" is
what you'd think.
However, most of them do not look at or modify the
pending-number flag at all, which means a number may "jump"
across a significant keyword and be used unexpectedly. For
example, when parsing:
January 5th noon pm
we'd connect the "5" to "pm", and ignore it as a
day-of-month. This is obviously a bit silly, as "noon"
already implies "pm". And other mis-parsed things are
generally as silly ("January 5th noon, years ago" would
connect the 5 to "years", but probably nobody would type
that).
However, the fix is simple: when we see a keyword like
"noon", we should flush the pending number (as we would if
we hit another number, or the end of the string). In a few
of the specials that actually modify the day, we can simply
throw away the number (saying "Jan 5 yesterday" should not
respect the number at all).
Note that we have to either move or forward-declare the
static pending_number() to make it accessible to these
functions; this patch moves it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02 05:23:09 +00:00
|
|
|
pending_number(tm, num);
|
2009-08-22 22:10:07 +00:00
|
|
|
date_time(tm, now, 0);
|
2005-11-18 16:56:40 +00:00
|
|
|
}
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
static void date_noon(struct tm *tm, struct tm *now, int *num)
|
2005-11-18 16:56:40 +00:00
|
|
|
{
|
approxidate: handle pending number for "specials"
The approxidate parser has a table of special keywords like
"yesterday", "noon", "pm", etc. Some of these, like "pm", do
the right thing if we've recently seen a number: "3pm" is
what you'd think.
However, most of them do not look at or modify the
pending-number flag at all, which means a number may "jump"
across a significant keyword and be used unexpectedly. For
example, when parsing:
January 5th noon pm
we'd connect the "5" to "pm", and ignore it as a
day-of-month. This is obviously a bit silly, as "noon"
already implies "pm". And other mis-parsed things are
generally as silly ("January 5th noon, years ago" would
connect the 5 to "years", but probably nobody would type
that).
However, the fix is simple: when we see a keyword like
"noon", we should flush the pending number (as we would if
we hit another number, or the end of the string). In a few
of the specials that actually modify the day, we can simply
throw away the number (saying "Jan 5 yesterday" should not
respect the number at all).
Note that we have to either move or forward-declare the
static pending_number() to make it accessible to these
functions; this patch moves it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02 05:23:09 +00:00
|
|
|
pending_number(tm, num);
|
2009-08-22 22:10:07 +00:00
|
|
|
date_time(tm, now, 12);
|
2005-11-18 16:56:40 +00:00
|
|
|
}
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
static void date_tea(struct tm *tm, struct tm *now, int *num)
|
2005-11-18 16:56:40 +00:00
|
|
|
{
|
approxidate: handle pending number for "specials"
The approxidate parser has a table of special keywords like
"yesterday", "noon", "pm", etc. Some of these, like "pm", do
the right thing if we've recently seen a number: "3pm" is
what you'd think.
However, most of them do not look at or modify the
pending-number flag at all, which means a number may "jump"
across a significant keyword and be used unexpectedly. For
example, when parsing:
January 5th noon pm
we'd connect the "5" to "pm", and ignore it as a
day-of-month. This is obviously a bit silly, as "noon"
already implies "pm". And other mis-parsed things are
generally as silly ("January 5th noon, years ago" would
connect the 5 to "years", but probably nobody would type
that).
However, the fix is simple: when we see a keyword like
"noon", we should flush the pending number (as we would if
we hit another number, or the end of the string). In a few
of the specials that actually modify the day, we can simply
throw away the number (saying "Jan 5 yesterday" should not
respect the number at all).
Note that we have to either move or forward-declare the
static pending_number() to make it accessible to these
functions; this patch moves it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02 05:23:09 +00:00
|
|
|
pending_number(tm, num);
|
2009-08-22 22:10:07 +00:00
|
|
|
date_time(tm, now, 17);
|
2005-11-18 16:56:40 +00:00
|
|
|
}
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
static void date_pm(struct tm *tm, struct tm *now, int *num)
|
2006-09-28 19:14:27 +00:00
|
|
|
{
|
2006-09-29 19:36:13 +00:00
|
|
|
int hour, n = *num;
|
2006-09-28 19:14:27 +00:00
|
|
|
*num = 0;
|
|
|
|
|
2006-09-29 19:36:13 +00:00
|
|
|
hour = tm->tm_hour;
|
|
|
|
if (n) {
|
|
|
|
hour = n;
|
2006-09-28 19:14:27 +00:00
|
|
|
tm->tm_min = 0;
|
|
|
|
tm->tm_sec = 0;
|
|
|
|
}
|
2006-09-29 19:36:13 +00:00
|
|
|
tm->tm_hour = (hour % 12) + 12;
|
2006-09-28 19:14:27 +00:00
|
|
|
}
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
static void date_am(struct tm *tm, struct tm *now, int *num)
|
2006-09-28 19:14:27 +00:00
|
|
|
{
|
2006-09-29 19:36:13 +00:00
|
|
|
int hour, n = *num;
|
2006-09-28 19:14:27 +00:00
|
|
|
*num = 0;
|
|
|
|
|
2006-09-29 19:36:13 +00:00
|
|
|
hour = tm->tm_hour;
|
|
|
|
if (n) {
|
|
|
|
hour = n;
|
2006-09-28 19:14:27 +00:00
|
|
|
tm->tm_min = 0;
|
|
|
|
tm->tm_sec = 0;
|
|
|
|
}
|
2006-09-29 19:36:13 +00:00
|
|
|
tm->tm_hour = (hour % 12);
|
2006-09-28 19:14:27 +00:00
|
|
|
}
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
static void date_never(struct tm *tm, struct tm *now, int *num)
|
2007-07-24 18:18:34 +00:00
|
|
|
{
|
2008-06-17 16:34:57 +00:00
|
|
|
time_t n = 0;
|
|
|
|
localtime_r(&n, tm);
|
approxidate: handle pending number for "specials"
The approxidate parser has a table of special keywords like
"yesterday", "noon", "pm", etc. Some of these, like "pm", do
the right thing if we've recently seen a number: "3pm" is
what you'd think.
However, most of them do not look at or modify the
pending-number flag at all, which means a number may "jump"
across a significant keyword and be used unexpectedly. For
example, when parsing:
January 5th noon pm
we'd connect the "5" to "pm", and ignore it as a
day-of-month. This is obviously a bit silly, as "noon"
already implies "pm". And other mis-parsed things are
generally as silly ("January 5th noon, years ago" would
connect the 5 to "years", but probably nobody would type
that).
However, the fix is simple: when we see a keyword like
"noon", we should flush the pending number (as we would if
we hit another number, or the end of the string). In a few
of the specials that actually modify the day, we can simply
throw away the number (saying "Jan 5 yesterday" should not
respect the number at all).
Note that we have to either move or forward-declare the
static pending_number() to make it accessible to these
functions; this patch moves it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02 05:23:09 +00:00
|
|
|
*num = 0;
|
2007-07-24 18:18:34 +00:00
|
|
|
}
|
|
|
|
|
2005-11-18 16:56:40 +00:00
|
|
|
static const struct special {
|
|
|
|
const char *name;
|
2009-08-22 22:10:07 +00:00
|
|
|
void (*fn)(struct tm *, struct tm *, int *);
|
2005-11-18 16:56:40 +00:00
|
|
|
} special[] = {
|
|
|
|
{ "yesterday", date_yesterday },
|
|
|
|
{ "noon", date_noon },
|
|
|
|
{ "midnight", date_midnight },
|
|
|
|
{ "tea", date_tea },
|
2006-09-28 19:14:27 +00:00
|
|
|
{ "PM", date_pm },
|
|
|
|
{ "AM", date_am },
|
2007-07-24 18:18:34 +00:00
|
|
|
{ "never", date_never },
|
2010-01-26 19:58:00 +00:00
|
|
|
{ "now", date_now },
|
2005-11-18 16:56:40 +00:00
|
|
|
{ NULL }
|
|
|
|
};
|
|
|
|
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
static const char *number_name[] = {
|
|
|
|
"zero", "one", "two", "three", "four",
|
|
|
|
"five", "six", "seven", "eight", "nine", "ten",
|
|
|
|
};
|
|
|
|
|
2005-11-18 16:56:40 +00:00
|
|
|
static const struct typelen {
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
const char *type;
|
|
|
|
int length;
|
|
|
|
} typelen[] = {
|
|
|
|
{ "seconds", 1 },
|
|
|
|
{ "minutes", 60 },
|
|
|
|
{ "hours", 60*60 },
|
|
|
|
{ "days", 24*60*60 },
|
|
|
|
{ "weeks", 7*24*60*60 },
|
|
|
|
{ NULL }
|
2007-06-07 07:04:01 +00:00
|
|
|
};
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
|
2010-01-26 19:58:00 +00:00
|
|
|
static const char *approxidate_alpha(const char *date, struct tm *tm, struct tm *now, int *num, int *touched)
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
{
|
2005-11-18 16:56:40 +00:00
|
|
|
const struct typelen *tl;
|
|
|
|
const struct special *s;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
const char *end = date;
|
2006-08-23 10:39:16 +00:00
|
|
|
int i;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
|
2013-10-24 08:42:17 +00:00
|
|
|
while (isalpha(*++end))
|
2006-08-23 10:39:16 +00:00
|
|
|
;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
|
|
|
|
for (i = 0; i < 12; i++) {
|
|
|
|
int match = match_string(date, month_names[i]);
|
|
|
|
if (match >= 3) {
|
|
|
|
tm->tm_mon = i;
|
2010-01-26 19:58:00 +00:00
|
|
|
*touched = 1;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
return end;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-11-18 16:56:40 +00:00
|
|
|
for (s = special; s->name; s++) {
|
|
|
|
int len = strlen(s->name);
|
|
|
|
if (match_string(date, s->name) == len) {
|
2009-08-22 22:10:07 +00:00
|
|
|
s->fn(tm, now, num);
|
2010-01-26 19:58:00 +00:00
|
|
|
*touched = 1;
|
2005-11-18 16:56:40 +00:00
|
|
|
return end;
|
|
|
|
}
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!*num) {
|
|
|
|
for (i = 1; i < 11; i++) {
|
|
|
|
int len = strlen(number_name[i]);
|
|
|
|
if (match_string(date, number_name[i]) == len) {
|
|
|
|
*num = i;
|
2010-01-26 19:58:00 +00:00
|
|
|
*touched = 1;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
return end;
|
|
|
|
}
|
|
|
|
}
|
2010-01-26 19:58:00 +00:00
|
|
|
if (match_string(date, "last") == 4) {
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
*num = 1;
|
2010-01-26 19:58:00 +00:00
|
|
|
*touched = 1;
|
|
|
|
}
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
|
|
|
tl = typelen;
|
|
|
|
while (tl->type) {
|
|
|
|
int len = strlen(tl->type);
|
|
|
|
if (match_string(date, tl->type) >= len-1) {
|
2009-08-22 22:10:07 +00:00
|
|
|
update_tm(tm, now, tl->length * *num);
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
*num = 0;
|
2010-01-26 19:58:00 +00:00
|
|
|
*touched = 1;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
return end;
|
|
|
|
}
|
|
|
|
tl++;
|
|
|
|
}
|
|
|
|
|
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>
2005-11-17 20:36:30 +00:00
|
|
|
for (i = 0; i < 7; i++) {
|
|
|
|
int match = match_string(date, weekday_names[i]);
|
|
|
|
if (match >= 3) {
|
|
|
|
int diff, n = *num -1;
|
|
|
|
*num = 0;
|
|
|
|
|
|
|
|
diff = tm->tm_wday - i;
|
|
|
|
if (diff <= 0)
|
|
|
|
n++;
|
|
|
|
diff += 7*n;
|
|
|
|
|
2009-08-22 22:10:07 +00:00
|
|
|
update_tm(tm, now, diff * 24 * 60 * 60);
|
2010-01-26 19:58:00 +00:00
|
|
|
*touched = 1;
|
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>
2005-11-17 20:36:30 +00:00
|
|
|
return end;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
if (match_string(date, "months") >= 5) {
|
2009-08-31 02:31:42 +00:00
|
|
|
int n;
|
|
|
|
update_tm(tm, now, 0); /* fill in date fields if needed */
|
|
|
|
n = tm->tm_mon - *num;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
*num = 0;
|
|
|
|
while (n < 0) {
|
|
|
|
n += 12;
|
|
|
|
tm->tm_year--;
|
|
|
|
}
|
|
|
|
tm->tm_mon = n;
|
2010-01-26 19:58:00 +00:00
|
|
|
*touched = 1;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (match_string(date, "years") >= 4) {
|
2009-08-31 02:31:42 +00:00
|
|
|
update_tm(tm, now, 0); /* fill in date fields if needed */
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
tm->tm_year -= *num;
|
|
|
|
*num = 0;
|
2010-01-26 19:58:00 +00:00
|
|
|
*touched = 1;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
2014-11-13 11:04:52 +00:00
|
|
|
static const char *approxidate_digit(const char *date, struct tm *tm, int *num,
|
|
|
|
time_t now)
|
2006-09-28 19:12:28 +00:00
|
|
|
{
|
|
|
|
char *end;
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t number = parse_timestamp(date, &end, 10);
|
2006-09-28 19:12:28 +00:00
|
|
|
|
2006-09-28 19:14:27 +00:00
|
|
|
switch (*end) {
|
|
|
|
case ':':
|
|
|
|
case '.':
|
|
|
|
case '/':
|
|
|
|
case '-':
|
|
|
|
if (isdigit(end[1])) {
|
2014-11-13 11:04:52 +00:00
|
|
|
int match = match_multi_number(number, *end, date, end,
|
|
|
|
tm, now);
|
2006-09-28 19:14:27 +00:00
|
|
|
if (match)
|
|
|
|
return date + match;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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 04:25:40 +00:00
|
|
|
/* Accept zero-padding only for small numbers ("Dec 02", never "Dec 0002") */
|
|
|
|
if (date[0] != '0' || end - date <= 2)
|
|
|
|
*num = number;
|
2006-09-28 19:12:28 +00:00
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
static timestamp_t approxidate_str(const char *date,
|
|
|
|
const struct timeval *tv,
|
|
|
|
int *error_ret)
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
{
|
|
|
|
int number = 0;
|
2010-01-26 19:58:00 +00:00
|
|
|
int touched = 0;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
struct tm tm, now;
|
2009-04-06 17:26:37 +00:00
|
|
|
time_t time_sec;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
|
2009-08-31 02:26:05 +00:00
|
|
|
time_sec = tv->tv_sec;
|
2009-04-06 17:26:37 +00:00
|
|
|
localtime_r(&time_sec, &tm);
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
now = tm;
|
2009-08-22 22:10:07 +00:00
|
|
|
|
|
|
|
tm.tm_year = -1;
|
|
|
|
tm.tm_mon = -1;
|
|
|
|
tm.tm_mday = -1;
|
|
|
|
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
for (;;) {
|
|
|
|
unsigned char c = *date;
|
|
|
|
if (!c)
|
|
|
|
break;
|
|
|
|
date++;
|
|
|
|
if (isdigit(c)) {
|
2009-08-22 22:10:07 +00:00
|
|
|
pending_number(&tm, &number);
|
2014-11-13 11:04:52 +00:00
|
|
|
date = approxidate_digit(date-1, &tm, &number, time_sec);
|
2010-01-26 19:58:00 +00:00
|
|
|
touched = 1;
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (isalpha(c))
|
2010-01-26 19:58:00 +00:00
|
|
|
date = approxidate_alpha(date-1, &tm, &now, &number, &touched);
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
}
|
2009-08-22 22:10:07 +00:00
|
|
|
pending_number(&tm, &number);
|
2010-01-26 19:58:00 +00:00
|
|
|
if (!touched)
|
|
|
|
*error_ret = 1;
|
2017-04-26 19:29:31 +00:00
|
|
|
return (timestamp_t)update_tm(&tm, &now, 0);
|
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>
2005-11-15 03:29:06 +00:00
|
|
|
}
|
2009-08-31 02:26:05 +00:00
|
|
|
|
2019-09-12 04:11:01 +00:00
|
|
|
timestamp_t approxidate_relative(const char *date)
|
2009-08-31 02:26:05 +00:00
|
|
|
{
|
2019-09-12 04:11:01 +00:00
|
|
|
struct timeval tv;
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t timestamp;
|
2010-06-03 20:28:55 +00:00
|
|
|
int offset;
|
2010-01-26 19:58:00 +00:00
|
|
|
int errors = 0;
|
2009-08-31 02:26:05 +00:00
|
|
|
|
2010-07-15 16:22:57 +00:00
|
|
|
if (!parse_date_basic(date, ×tamp, &offset))
|
2010-06-03 20:28:55 +00:00
|
|
|
return timestamp;
|
2019-09-12 04:11:01 +00:00
|
|
|
|
|
|
|
get_time(&tv);
|
|
|
|
return approxidate_str(date, (const struct timeval *) &tv, &errors);
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t approxidate_careful(const char *date, int *error_ret)
|
2009-08-31 02:26:05 +00:00
|
|
|
{
|
|
|
|
struct timeval tv;
|
2017-04-26 19:29:31 +00:00
|
|
|
timestamp_t timestamp;
|
2010-06-03 20:28:55 +00:00
|
|
|
int offset;
|
2010-01-26 19:58:00 +00:00
|
|
|
int dummy = 0;
|
|
|
|
if (!error_ret)
|
|
|
|
error_ret = &dummy;
|
2009-08-31 02:26:05 +00:00
|
|
|
|
2010-07-15 16:22:57 +00:00
|
|
|
if (!parse_date_basic(date, ×tamp, &offset)) {
|
2010-01-26 19:58:00 +00:00
|
|
|
*error_ret = 0;
|
2010-06-03 20:28:55 +00:00
|
|
|
return timestamp;
|
2010-01-26 19:58:00 +00:00
|
|
|
}
|
2009-08-31 02:26:05 +00:00
|
|
|
|
2019-01-29 03:50:15 +00:00
|
|
|
get_time(&tv);
|
2010-01-26 19:58:00 +00:00
|
|
|
return approxidate_str(date, &tv, error_ret);
|
2009-08-31 02:26:05 +00:00
|
|
|
}
|
2014-02-24 07:39:45 +00:00
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
int date_overflows(timestamp_t t)
|
2014-02-24 07:39:45 +00:00
|
|
|
{
|
|
|
|
time_t sys;
|
|
|
|
|
2017-04-26 19:29:31 +00:00
|
|
|
/* If we overflowed our timestamp data type, that's bad... */
|
|
|
|
if ((uintmax_t)t >= TIME_MAX)
|
2014-02-24 07:39:45 +00:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ...but we also are going to feed the result to system
|
|
|
|
* functions that expect time_t, which is often "signed long".
|
|
|
|
* Make sure that we fit into time_t, as well.
|
|
|
|
*/
|
|
|
|
sys = t;
|
|
|
|
return t != sys || (t < 1) != (sys < 1);
|
|
|
|
}
|