|
|
|
/*
|
|
|
|
* GIT - The information manager from hell
|
|
|
|
*
|
|
|
|
* Copyright (C) Linus Torvalds, 2005
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "cache.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is like mktime, but without normalization of tm_wday and tm_yday.
|
|
|
|
*/
|
|
|
|
time_t tm_to_time_t(const struct tm *tm)
|
|
|
|
{
|
|
|
|
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--;
|
|
|
|
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[] = {
|
|
|
|
"January", "February", "March", "April", "May", "June",
|
|
|
|
"July", "August", "September", "October", "November", "December"
|
|
|
|
};
|
|
|
|
|
|
|
|
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>
19 years ago
|
|
|
"Sundays", "Mondays", "Tuesdays", "Wednesdays", "Thursdays", "Fridays", "Saturdays"
|
|
|
|
};
|
|
|
|
|
|
|
|
static time_t gm_time_t(unsigned long time, int tz)
|
|
|
|
{
|
|
|
|
int minutes;
|
|
|
|
|
|
|
|
minutes = tz < 0 ? -tz : tz;
|
|
|
|
minutes = (minutes / 100)*60 + (minutes % 100);
|
|
|
|
minutes = tz < 0 ? -minutes : minutes;
|
|
|
|
return time + minutes * 60;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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"
|
|
|
|
*/
|
|
|
|
static struct tm *time_to_tm(unsigned long time, int tz)
|
|
|
|
{
|
|
|
|
time_t t = gm_time_t(time, tz);
|
|
|
|
return gmtime(&t);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* What value of "tz" was in effect back then at "time" in the
|
|
|
|
* local timezone?
|
|
|
|
*/
|
|
|
|
static int local_tzoffset(unsigned long time)
|
|
|
|
{
|
|
|
|
time_t t, t_local;
|
|
|
|
struct tm tm;
|
|
|
|
int offset, eastwest;
|
|
|
|
|
|
|
|
t = time;
|
|
|
|
localtime_r(&t, &tm);
|
|
|
|
t_local = tm_to_time_t(&tm);
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *show_date(unsigned long time, int tz, enum date_mode mode)
|
|
|
|
{
|
|
|
|
struct tm *tm;
|
|
|
|
static char timebuf[200];
|
|
|
|
|
|
|
|
if (mode == DATE_RAW) {
|
|
|
|
snprintf(timebuf, sizeof(timebuf), "%lu %+05d", time, tz);
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mode == DATE_RELATIVE) {
|
|
|
|
unsigned long diff;
|
|
|
|
struct timeval now;
|
|
|
|
gettimeofday(&now, NULL);
|
|
|
|
if (now.tv_sec < time)
|
|
|
|
return "in the future";
|
|
|
|
diff = now.tv_sec - time;
|
|
|
|
if (diff < 90) {
|
|
|
|
snprintf(timebuf, sizeof(timebuf), "%lu seconds ago", diff);
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
/* Turn it into minutes */
|
|
|
|
diff = (diff + 30) / 60;
|
|
|
|
if (diff < 90) {
|
|
|
|
snprintf(timebuf, sizeof(timebuf), "%lu minutes ago", diff);
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
/* Turn it into hours */
|
|
|
|
diff = (diff + 30) / 60;
|
|
|
|
if (diff < 36) {
|
|
|
|
snprintf(timebuf, sizeof(timebuf), "%lu hours ago", diff);
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
/* We deal with number of days from here on */
|
|
|
|
diff = (diff + 12) / 24;
|
|
|
|
if (diff < 14) {
|
|
|
|
snprintf(timebuf, sizeof(timebuf), "%lu days ago", diff);
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
/* Say weeks for the past 10 weeks or so */
|
|
|
|
if (diff < 70) {
|
|
|
|
snprintf(timebuf, sizeof(timebuf), "%lu weeks ago", (diff + 3) / 7);
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
/* Say months for the past 12 months or so */
|
|
|
|
if (diff < 360) {
|
|
|
|
snprintf(timebuf, sizeof(timebuf), "%lu months ago", (diff + 15) / 30);
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
/* Give years and months for 5 years or so */
|
|
|
|
if (diff < 1825) {
|
|
|
|
unsigned long years = (diff + 183) / 365;
|
|
|
|
unsigned long months = (diff % 365 + 15) / 30;
|
|
|
|
int n;
|
|
|
|
n = snprintf(timebuf, sizeof(timebuf), "%lu year%s",
|
|
|
|
years, (years > 1 ? "s" : ""));
|
|
|
|
if (months)
|
|
|
|
snprintf(timebuf + n, sizeof(timebuf) - n,
|
|
|
|
", %lu month%s ago",
|
|
|
|
months, (months > 1 ? "s" : ""));
|
|
|
|
else
|
|
|
|
snprintf(timebuf + n, sizeof(timebuf) - n,
|
|
|
|
" ago");
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
/* Otherwise, just years. Centuries is probably overkill. */
|
|
|
|
snprintf(timebuf, sizeof(timebuf), "%lu years ago", (diff + 183) / 365);
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mode == DATE_LOCAL)
|
|
|
|
tz = local_tzoffset(time);
|
|
|
|
|
|
|
|
tm = time_to_tm(time, tz);
|
|
|
|
if (!tm)
|
|
|
|
return NULL;
|
|
|
|
if (mode == DATE_SHORT)
|
|
|
|
sprintf(timebuf, "%04d-%02d-%02d", tm->tm_year + 1900,
|
|
|
|
tm->tm_mon + 1, tm->tm_mday);
|
|
|
|
else if (mode == DATE_ISO8601)
|
|
|
|
sprintf(timebuf, "%04d-%02d-%02d %02d:%02d:%02d %+05d",
|
|
|
|
tm->tm_year + 1900,
|
|
|
|
tm->tm_mon + 1,
|
|
|
|
tm->tm_mday,
|
|
|
|
tm->tm_hour, tm->tm_min, tm->tm_sec,
|
|
|
|
tz);
|
|
|
|
else if (mode == DATE_RFC2822)
|
|
|
|
sprintf(timebuf, "%.3s, %d %.3s %d %02d:%02d:%02d %+05d",
|
|
|
|
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);
|
|
|
|
else
|
|
|
|
sprintf(timebuf, "%.3s %.3s %d %02d:%02d:%02d %d%c%+05d",
|
|
|
|
weekday_names[tm->tm_wday],
|
|
|
|
month_names[tm->tm_mon],
|
|
|
|
tm->tm_mday,
|
|
|
|
tm->tm_hour, tm->tm_min, tm->tm_sec,
|
|
|
|
tm->tm_year + 1900,
|
|
|
|
(mode == DATE_LOCAL) ? 0 : ' ',
|
|
|
|
tz);
|
|
|
|
return timebuf;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
int dst;
|
|
|
|
} timezone_names[] = {
|
|
|
|
{ "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) */
|
|
|
|
|
|
|
|
{ "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 */
|
|
|
|
{ "EEST", +2, 1, }, /* Eastern European Daylight */
|
|
|
|
{ "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 */
|
|
|
|
{ "NZT", +12, 0, }, /* New Zealand */
|
|
|
|
{ "NZST", +12, 0, }, /* New Zealand Standard */
|
|
|
|
{ "NZDT", +12, 1, }, /* New Zealand Daylight */
|
|
|
|
{ "IDLE", +12, 0, }, /* International Date Line East */
|
|
|
|
};
|
|
|
|
|
|
|
|
static int match_string(const char *date, const char *str)
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int skip_alpha(const char *date)
|
|
|
|
{
|
|
|
|
int i = 0;
|
|
|
|
do {
|
|
|
|
i++;
|
|
|
|
} while (isalpha(date[i]));
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Parse month, weekday, or timezone name
|
|
|
|
*/
|
|
|
|
static int match_alpha(const char *date, struct tm *tm, int *offset)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 12; i++) {
|
|
|
|
int match = match_string(date, month_names[i]);
|
|
|
|
if (match >= 3) {
|
|
|
|
tm->tm_mon = i;
|
|
|
|
return match;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < 7; i++) {
|
|
|
|
int match = match_string(date, weekday_names[i]);
|
|
|
|
if (match >= 3) {
|
|
|
|
tm->tm_wday = i;
|
|
|
|
return match;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(timezone_names); i++) {
|
|
|
|
int match = match_string(date, timezone_names[i].name);
|
|
|
|
if (match >= 3) {
|
|
|
|
int off = timezone_names[i].offset;
|
|
|
|
|
|
|
|
/* This is bogus, but we like summer */
|
|
|
|
off += timezone_names[i].dst;
|
|
|
|
|
|
|
|
/* Only use the tz name offset if we don't have anything better */
|
|
|
|
if (*offset == -1)
|
|
|
|
*offset = 60*off;
|
|
|
|
|
|
|
|
return match;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (match_string(date, "PM") == 2) {
|
|
|
|
tm->tm_hour = (tm->tm_hour % 12) + 12;
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (match_string(date, "AM") == 2) {
|
|
|
|
tm->tm_hour = (tm->tm_hour % 12) + 0;
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* BAD CRAP */
|
|
|
|
return skip_alpha(date);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int is_date(int year, int month, int day, struct tm *now_tm, time_t now, struct tm *tm)
|
|
|
|
{
|
|
|
|
if (month > 0 && month < 13 && day > 0 && day < 32) {
|
|
|
|
struct tm check = *tm;
|
|
|
|
struct tm *r = (now_tm ? &check : tm);
|
|
|
|
time_t specified;
|
|
|
|
|
|
|
|
r->tm_mon = month - 1;
|
|
|
|
r->tm_mday = day;
|
|
|
|
if (year == -1) {
|
|
|
|
if (!now_tm)
|
|
|
|
return 1;
|
|
|
|
r->tm_year = now_tm->tm_year;
|
|
|
|
}
|
|
|
|
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
|
|
|
|
return 0;
|
|
|
|
if (!now_tm)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
specified = tm_to_time_t(r);
|
|
|
|
|
|
|
|
/* 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...
|
|
|
|
*/
|
|
|
|
if (now + 10*24*3600 < specified)
|
|
|
|
return 0;
|
|
|
|
tm->tm_mon = r->tm_mon;
|
|
|
|
tm->tm_mday = r->tm_mday;
|
|
|
|
if (year != -1)
|
|
|
|
tm->tm_year = r->tm_year;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int match_multi_number(unsigned long num, char c, const char *date, char *end, struct tm *tm)
|
|
|
|
{
|
|
|
|
time_t now;
|
|
|
|
struct tm now_tm;
|
|
|
|
struct tm *refuse_future;
|
|
|
|
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? */
|
|
|
|
switch (c) {
|
|
|
|
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;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
case '-':
|
|
|
|
case '/':
|
|
|
|
case '.':
|
|
|
|
now = time(NULL);
|
|
|
|
refuse_future = NULL;
|
|
|
|
if (gmtime_r(&now, &now_tm))
|
|
|
|
refuse_future = &now_tm;
|
|
|
|
|
|
|
|
if (num > 70) {
|
|
|
|
/* yyyy-mm-dd? */
|
|
|
|
if (is_date(num, num2, num3, refuse_future, now, tm))
|
|
|
|
break;
|
|
|
|
/* yyyy-dd-mm? */
|
|
|
|
if (is_date(num, num3, num2, refuse_future, now, tm))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* 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))
|
|
|
|
break;
|
|
|
|
/* Funny European mm.dd.yy */
|
|
|
|
if (c == '.' &&
|
|
|
|
is_date(num3, num, num2, refuse_future, now, tm))
|
|
|
|
break;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return end - date;
|
|
|
|
}
|
|
|
|
|
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>
17 years ago
|
|
|
/* Have we filled in any part of the time/date yet? */
|
|
|
|
static inline int nodate(struct tm *tm)
|
|
|
|
{
|
|
|
|
return tm->tm_year < 0 &&
|
|
|
|
tm->tm_mon < 0 &&
|
|
|
|
tm->tm_mday < 0 &&
|
|
|
|
!(tm->tm_hour | tm->tm_min | tm->tm_sec);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We've seen a digit. Time? Year? Date?
|
|
|
|
*/
|
|
|
|
static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt)
|
|
|
|
{
|
|
|
|
int n;
|
|
|
|
char *end;
|
|
|
|
unsigned long num;
|
|
|
|
|
|
|
|
num = strtoul(date, &end, 10);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
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>
17 years ago
|
|
|
if (num >= 100000000 && nodate(tm)) {
|
|
|
|
time_t time = num;
|
|
|
|
if (gmtime_r(&time, tm)) {
|
|
|
|
*tm_gmt = 1;
|
|
|
|
return end - date;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check for special formats: num[-.:/]num[same]num
|
|
|
|
*/
|
|
|
|
switch (*end) {
|
|
|
|
case ':':
|
|
|
|
case '.':
|
|
|
|
case '/':
|
|
|
|
case '-':
|
|
|
|
if (isdigit(end[1])) {
|
|
|
|
int match = match_multi_number(num, *end, date, end, tm);
|
|
|
|
if (match)
|
|
|
|
return match;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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) {
|
|
|
|
if (num <= 1400 && *offset == -1) {
|
|
|
|
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>
17 years ago
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE! We will give precedence to day-of-month over month or
|
|
|
|
* year numbers in the 1-12 range. So 05 is always "mday 5",
|
|
|
|
* 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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (num > 0 && num < 32) {
|
|
|
|
tm->tm_mday = num;
|
|
|
|
} else if (num > 0 && num < 13) {
|
|
|
|
tm->tm_mon = num-1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int match_tz(const char *date, int *offp)
|
|
|
|
{
|
|
|
|
char *end;
|
|
|
|
int offset = strtoul(date+1, &end, 10);
|
|
|
|
int min, hour;
|
|
|
|
int n = end - date - 1;
|
|
|
|
|
|
|
|
min = offset % 100;
|
|
|
|
hour = offset / 100;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't accept any random crap.. At least 3 digits, and
|
|
|
|
* a valid minute. We might want to check that the minutes
|
|
|
|
* are divisible by 30 or something too.
|
|
|
|
*/
|
|
|
|
if (min < 60 && n > 2) {
|
|
|
|
offset = hour*60+min;
|
|
|
|
if (*date == '-')
|
|
|
|
offset = -offset;
|
|
|
|
|
|
|
|
*offp = offset;
|
|
|
|
}
|
|
|
|
return end - date;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int date_string(unsigned long date, int offset, char *buf, int len)
|
|
|
|
{
|
|
|
|
int sign = '+';
|
|
|
|
|
|
|
|
if (offset < 0) {
|
|
|
|
offset = -offset;
|
|
|
|
sign = '-';
|
|
|
|
}
|
|
|
|
return snprintf(buf, len, "%lu %c%02d%02d", date, sign, offset / 60, offset % 60);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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. */
|
|
|
|
int parse_date(const char *date, char *result, int maxlen)
|
|
|
|
{
|
|
|
|
struct tm tm;
|
|
|
|
int offset, tm_gmt;
|
|
|
|
time_t then;
|
|
|
|
|
|
|
|
memset(&tm, 0, sizeof(tm));
|
|
|
|
tm.tm_year = -1;
|
|
|
|
tm.tm_mon = -1;
|
|
|
|
tm.tm_mday = -1;
|
|
|
|
tm.tm_isdst = -1;
|
|
|
|
offset = -1;
|
|
|
|
tm_gmt = 0;
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
int match = 0;
|
|
|
|
unsigned char c = *date;
|
|
|
|
|
|
|
|
/* Stop at end of string or newline */
|
|
|
|
if (!c || c == '\n')
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (isalpha(c))
|
|
|
|
match = match_alpha(date, &tm, &offset);
|
|
|
|
else if (isdigit(c))
|
|
|
|
match = match_digit(date, &tm, &offset, &tm_gmt);
|
|
|
|
else if ((c == '-' || c == '+') && isdigit(date[1]))
|
|
|
|
match = match_tz(date, &offset);
|
|
|
|
|
|
|
|
if (!match) {
|
|
|
|
/* BAD CRAP */
|
|
|
|
match = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
date += match;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* mktime uses local timezone */
|
|
|
|
then = tm_to_time_t(&tm);
|
|
|
|
if (offset == -1)
|
|
|
|
offset = (then - mktime(&tm)) / 60;
|
|
|
|
|
|
|
|
if (then == -1)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (!tm_gmt)
|
|
|
|
then -= offset * 60;
|
|
|
|
return date_string(then, offset, result, maxlen);
|
|
|
|
}
|
|
|
|
|
|
|
|
enum date_mode parse_date_format(const char *format)
|
|
|
|
{
|
|
|
|
if (!strcmp(format, "relative"))
|
|
|
|
return DATE_RELATIVE;
|
|
|
|
else if (!strcmp(format, "iso8601") ||
|
|
|
|
!strcmp(format, "iso"))
|
|
|
|
return DATE_ISO8601;
|
|
|
|
else if (!strcmp(format, "rfc2822") ||
|
|
|
|
!strcmp(format, "rfc"))
|
|
|
|
return DATE_RFC2822;
|
|
|
|
else if (!strcmp(format, "short"))
|
|
|
|
return DATE_SHORT;
|
|
|
|
else if (!strcmp(format, "local"))
|
|
|
|
return DATE_LOCAL;
|
|
|
|
else if (!strcmp(format, "default"))
|
|
|
|
return DATE_NORMAL;
|
|
|
|
else if (!strcmp(format, "raw"))
|
|
|
|
return DATE_RAW;
|
|
|
|
else
|
|
|
|
die("unknown date format %s", format);
|
|
|
|
}
|
|
|
|
|
|
|
|
void datestamp(char *buf, int bufsize)
|
|
|
|
{
|
|
|
|
time_t now;
|
|
|
|
int offset;
|
|
|
|
|
|
|
|
time(&now);
|
|
|
|
|
|
|
|
offset = tm_to_time_t(localtime(&now)) - now;
|
|
|
|
offset /= 60;
|
|
|
|
|
|
|
|
date_string(now, offset, buf, bufsize);
|
|
|
|
}
|
git's rev-parse.c function show_datestring presumes gnu date
Ok. This is the insane patch to do this.
It really isn't very careful, and the reason I call it "approxidate()"
will become obvious when you look at the code. It is very liberal in what
it accepts, to the point where sometimes the results may not make a whole
lot of sense.
It accepts "last week" as a date string, by virtue of "last" parsing as
the number 1, and it totally ignoring superfluous fluff like "ago", so
"last week" ends up being exactly the same thing as "1 week ago". Fine so
far.
It has strange side effects: "last december" will actually parse as "Dec
1", which actually _does_ turn out right, because it will then notice that
it's not December yet, so it will decide that you must be talking about a
date last year. So it actually gets it right, but it's kind of for the
"wrong" reasons.
It also accepts the numbers 1..10 in string format ("one" .. "ten"), so
you can do "ten weeks ago" or "ten hours ago" and it will do the right
thing.
But it will do some really strange thigns too: the string "this will last
forever", will not recognize anyting but "last", which is recognized as
"1", which since it doesn't understand anything else it will think is the
day of the month. So if you do
gitk --since="this will last forever"
the date will actually parse as the first day of the current month.
And it will parse the string "now" as "now", but only because it doesn't
understand it at all, and it makes everything relative to "now".
Similarly, it doesn't actually parse the "ago" or "from now", so "2 weeks
ago" is exactly the same as "2 weeks from now". It's the current date
minus 14 days.
But hey, it's probably better (and certainly faster) than depending on GNU
date. So now you can portably do things like
gitk --since="two weeks and three days ago"
git log --since="July 5"
git-whatchanged --since="10 hours ago"
git log --since="last october"
and it will actually do exactly what you thought it would do (I think). It
will count 17 days backwards, and it will do so even if you don't have GNU
date installed.
(I don't do "last monday" or similar yet, but I can extend it to that too
if people want).
It was kind of fun trying to write code that uses such totally relaxed
"understanding" of dates yet tries to get it right for the trivial cases.
The result should be mixed with a few strange preprocessor tricks, and be
submitted for the IOCCC ;)
Feel free to try it out, and see how many strange dates it gets right. Or
wrong.
And if you find some interesting (and valid - not "interesting" as in
"strange", but "interesting" as in "I'd be interested in actually doing
this) thing it gets wrong - usually by not understanding it and silently
just doing some strange things - please holler.
Now, as usual this certainly hasn't been getting a lot of testing. But my
code always works, no?
Linus
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
|
|
|
|
static void update_tm(struct tm *tm, unsigned long sec)
|
|
|
|
{
|
|
|
|
time_t n = mktime(tm) - sec;
|
|
|
|
localtime_r(&n, tm);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void date_yesterday(struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
update_tm(tm, 24*60*60);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void date_time(struct tm *tm, int hour)
|
|
|
|
{
|
|
|
|
if (tm->tm_hour < hour)
|
|
|
|
date_yesterday(tm, NULL);
|
|
|
|
tm->tm_hour = hour;
|
|
|
|
tm->tm_min = 0;
|
|
|
|
tm->tm_sec = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void date_midnight(struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
date_time(tm, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void date_noon(struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
date_time(tm, 12);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void date_tea(struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
date_time(tm, 17);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void date_pm(struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
int hour, n = *num;
|
|
|
|
*num = 0;
|
|
|
|
|
|
|
|
hour = tm->tm_hour;
|
|
|
|
if (n) {
|
|
|
|
hour = n;
|
|
|
|
tm->tm_min = 0;
|
|
|
|
tm->tm_sec = 0;
|
|
|
|
}
|
|
|
|
tm->tm_hour = (hour % 12) + 12;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void date_am(struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
int hour, n = *num;
|
|
|
|
*num = 0;
|
|
|
|
|
|
|
|
hour = tm->tm_hour;
|
|
|
|
if (n) {
|
|
|
|
hour = n;
|
|
|
|
tm->tm_min = 0;
|
|
|
|
tm->tm_sec = 0;
|
|
|
|
}
|
|
|
|
tm->tm_hour = (hour % 12);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void date_never(struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
time_t n = 0;
|
|
|
|
localtime_r(&n, tm);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct special {
|
|
|
|
const char *name;
|
|
|
|
void (*fn)(struct tm *, int *);
|
|
|
|
} special[] = {
|
|
|
|
{ "yesterday", date_yesterday },
|
|
|
|
{ "noon", date_noon },
|
|
|
|
{ "midnight", date_midnight },
|
|
|
|
{ "tea", date_tea },
|
|
|
|
{ "PM", date_pm },
|
|
|
|
{ "AM", date_am },
|
|
|
|
{ "never", date_never },
|
|
|
|
{ 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>
19 years ago
|
|
|
static const char *number_name[] = {
|
|
|
|
"zero", "one", "two", "three", "four",
|
|
|
|
"five", "six", "seven", "eight", "nine", "ten",
|
|
|
|
};
|
|
|
|
|
|
|
|
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>
19 years ago
|
|
|
const char *type;
|
|
|
|
int length;
|
|
|
|
} typelen[] = {
|
|
|
|
{ "seconds", 1 },
|
|
|
|
{ "minutes", 60 },
|
|
|
|
{ "hours", 60*60 },
|
|
|
|
{ "days", 24*60*60 },
|
|
|
|
{ "weeks", 7*24*60*60 },
|
|
|
|
{ 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>
19 years ago
|
|
|
|
|
|
|
static const char *approxidate_alpha(const char *date, struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
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>
19 years ago
|
|
|
const char *end = date;
|
|
|
|
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>
19 years ago
|
|
|
|
|
|
|
while (isalpha(*++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>
19 years ago
|
|
|
|
|
|
|
for (i = 0; i < 12; i++) {
|
|
|
|
int match = match_string(date, month_names[i]);
|
|
|
|
if (match >= 3) {
|
|
|
|
tm->tm_mon = i;
|
|
|
|
return end;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (s = special; s->name; s++) {
|
|
|
|
int len = strlen(s->name);
|
|
|
|
if (match_string(date, s->name) == len) {
|
|
|
|
s->fn(tm, num);
|
|
|
|
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>
19 years ago
|
|
|
}
|
|
|
|
|
|
|
|
if (!*num) {
|
|
|
|
for (i = 1; i < 11; i++) {
|
|
|
|
int len = strlen(number_name[i]);
|
|
|
|
if (match_string(date, number_name[i]) == len) {
|
|
|
|
*num = i;
|
|
|
|
return end;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (match_string(date, "last") == 4)
|
|
|
|
*num = 1;
|
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
|
|
|
tl = typelen;
|
|
|
|
while (tl->type) {
|
|
|
|
int len = strlen(tl->type);
|
|
|
|
if (match_string(date, tl->type) >= len-1) {
|
|
|
|
update_tm(tm, tl->length * *num);
|
|
|
|
*num = 0;
|
|
|
|
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>
19 years ago
|
|
|
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;
|
|
|
|
|
|
|
|
update_tm(tm, diff * 24 * 60 * 60);
|
|
|
|
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>
19 years ago
|
|
|
if (match_string(date, "months") >= 5) {
|
|
|
|
int n = tm->tm_mon - *num;
|
|
|
|
*num = 0;
|
|
|
|
while (n < 0) {
|
|
|
|
n += 12;
|
|
|
|
tm->tm_year--;
|
|
|
|
}
|
|
|
|
tm->tm_mon = n;
|
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (match_string(date, "years") >= 4) {
|
|
|
|
tm->tm_year -= *num;
|
|
|
|
*num = 0;
|
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
|
|
|
return end;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char *approxidate_digit(const char *date, struct tm *tm, int *num)
|
|
|
|
{
|
|
|
|
char *end;
|
|
|
|
unsigned long number = strtoul(date, &end, 10);
|
|
|
|
|
|
|
|
switch (*end) {
|
|
|
|
case ':':
|
|
|
|
case '.':
|
|
|
|
case '/':
|
|
|
|
case '-':
|
|
|
|
if (isdigit(end[1])) {
|
|
|
|
int match = match_multi_number(number, *end, date, end, tm);
|
|
|
|
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>
17 years ago
|
|
|
/* Accept zero-padding only for small numbers ("Dec 02", never "Dec 0002") */
|
|
|
|
if (date[0] != '0' || end - date <= 2)
|
|
|
|
*num = number;
|
|
|
|
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>
19 years ago
|
|
|
unsigned long approxidate(const char *date)
|
|
|
|
{
|
|
|
|
int number = 0;
|
|
|
|
struct tm tm, now;
|
|
|
|
struct timeval tv;
|
|
|
|
char buffer[50];
|
|
|
|
|
|
|
|
if (parse_date(date, buffer, sizeof(buffer)) > 0)
|
|
|
|
return strtoul(buffer, NULL, 10);
|
|
|
|
|
|
|
|
gettimeofday(&tv, NULL);
|
|
|
|
localtime_r(&tv.tv_sec, &tm);
|
|
|
|
now = tm;
|
|
|
|
for (;;) {
|
|
|
|
unsigned char c = *date;
|
|
|
|
if (!c)
|
|
|
|
break;
|
|
|
|
date++;
|
|
|
|
if (isdigit(c)) {
|
|
|
|
date = approxidate_digit(date-1, &tm, &number);
|
git's rev-parse.c function show_datestring presumes gnu date
Ok. This is the insane patch to do this.
It really isn't very careful, and the reason I call it "approxidate()"
will become obvious when you look at the code. It is very liberal in what
it accepts, to the point where sometimes the results may not make a whole
lot of sense.
It accepts "last week" as a date string, by virtue of "last" parsing as
the number 1, and it totally ignoring superfluous fluff like "ago", so
"last week" ends up being exactly the same thing as "1 week ago". Fine so
far.
It has strange side effects: "last december" will actually parse as "Dec
1", which actually _does_ turn out right, because it will then notice that
it's not December yet, so it will decide that you must be talking about a
date last year. So it actually gets it right, but it's kind of for the
"wrong" reasons.
It also accepts the numbers 1..10 in string format ("one" .. "ten"), so
you can do "ten weeks ago" or "ten hours ago" and it will do the right
thing.
But it will do some really strange thigns too: the string "this will last
forever", will not recognize anyting but "last", which is recognized as
"1", which since it doesn't understand anything else it will think is the
day of the month. So if you do
gitk --since="this will last forever"
the date will actually parse as the first day of the current month.
And it will parse the string "now" as "now", but only because it doesn't
understand it at all, and it makes everything relative to "now".
Similarly, it doesn't actually parse the "ago" or "from now", so "2 weeks
ago" is exactly the same as "2 weeks from now". It's the current date
minus 14 days.
But hey, it's probably better (and certainly faster) than depending on GNU
date. So now you can portably do things like
gitk --since="two weeks and three days ago"
git log --since="July 5"
git-whatchanged --since="10 hours ago"
git log --since="last october"
and it will actually do exactly what you thought it would do (I think). It
will count 17 days backwards, and it will do so even if you don't have GNU
date installed.
(I don't do "last monday" or similar yet, but I can extend it to that too
if people want).
It was kind of fun trying to write code that uses such totally relaxed
"understanding" of dates yet tries to get it right for the trivial cases.
The result should be mixed with a few strange preprocessor tricks, and be
submitted for the IOCCC ;)
Feel free to try it out, and see how many strange dates it gets right. Or
wrong.
And if you find some interesting (and valid - not "interesting" as in
"strange", but "interesting" as in "I'd be interested in actually doing
this) thing it gets wrong - usually by not understanding it and silently
just doing some strange things - please holler.
Now, as usual this certainly hasn't been getting a lot of testing. But my
code always works, no?
Linus
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (isalpha(c))
|
|
|
|
date = approxidate_alpha(date-1, &tm, &number);
|
|
|
|
}
|
|
|
|
if (number > 0 && number < 32)
|
|
|
|
tm.tm_mday = number;
|
|
|
|
if (tm.tm_mon > now.tm_mon && tm.tm_year == now.tm_year)
|
git's rev-parse.c function show_datestring presumes gnu date
Ok. This is the insane patch to do this.
It really isn't very careful, and the reason I call it "approxidate()"
will become obvious when you look at the code. It is very liberal in what
it accepts, to the point where sometimes the results may not make a whole
lot of sense.
It accepts "last week" as a date string, by virtue of "last" parsing as
the number 1, and it totally ignoring superfluous fluff like "ago", so
"last week" ends up being exactly the same thing as "1 week ago". Fine so
far.
It has strange side effects: "last december" will actually parse as "Dec
1", which actually _does_ turn out right, because it will then notice that
it's not December yet, so it will decide that you must be talking about a
date last year. So it actually gets it right, but it's kind of for the
"wrong" reasons.
It also accepts the numbers 1..10 in string format ("one" .. "ten"), so
you can do "ten weeks ago" or "ten hours ago" and it will do the right
thing.
But it will do some really strange thigns too: the string "this will last
forever", will not recognize anyting but "last", which is recognized as
"1", which since it doesn't understand anything else it will think is the
day of the month. So if you do
gitk --since="this will last forever"
the date will actually parse as the first day of the current month.
And it will parse the string "now" as "now", but only because it doesn't
understand it at all, and it makes everything relative to "now".
Similarly, it doesn't actually parse the "ago" or "from now", so "2 weeks
ago" is exactly the same as "2 weeks from now". It's the current date
minus 14 days.
But hey, it's probably better (and certainly faster) than depending on GNU
date. So now you can portably do things like
gitk --since="two weeks and three days ago"
git log --since="July 5"
git-whatchanged --since="10 hours ago"
git log --since="last october"
and it will actually do exactly what you thought it would do (I think). It
will count 17 days backwards, and it will do so even if you don't have GNU
date installed.
(I don't do "last monday" or similar yet, but I can extend it to that too
if people want).
It was kind of fun trying to write code that uses such totally relaxed
"understanding" of dates yet tries to get it right for the trivial cases.
The result should be mixed with a few strange preprocessor tricks, and be
submitted for the IOCCC ;)
Feel free to try it out, and see how many strange dates it gets right. Or
wrong.
And if you find some interesting (and valid - not "interesting" as in
"strange", but "interesting" as in "I'd be interested in actually doing
this) thing it gets wrong - usually by not understanding it and silently
just doing some strange things - please holler.
Now, as usual this certainly hasn't been getting a lot of testing. But my
code always works, no?
Linus
Signed-off-by: Junio C Hamano <junkio@cox.net>
19 years ago
|
|
|
tm.tm_year--;
|
|
|
|
return mktime(&tm);
|
|
|
|
}
|