On Mon, Oct 31, 2011 at 08:17:09PM +0400, Dmitry V. Levin wrote:
> Hi,
>
> git rev-parse --since=1970-01-01 (and other git commands that take
> date string arguments like --since) may fail when --since=1970-01-01 is
> given. Whether it fails or not depends on current time and timezone data.
> For example, "TZ=Europe/Paris git rev-parse --since=1970-01-01" fails two
> hours a day (between 00:00 and 02:00 CET), and those who use more eastern
> timezones are even less lucky. In artificial timezones like UTC-24 it
> always fails:
>
> $ TZ=UTC-24 git rev-parse --since=1970-01-01
> --max-age=18446744073709523490
Out of curiosity, why do you need to work with a time so close to that
date?
> The problem is that several internal git functions implicitly convert
> time_t to unsigned long, so when time_t gets negative, all date string
> processing breaks.
I don't think it's worth supporting negative time_t, but we should at
least avoid misconversion.
-- 8< --
Subject: [PATCH] Do not accept negative time_t
We use unsigned long internally to present time, negative value just
breaks thing.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
---
date.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/date.c b/date.c
index 353e0a5..9cbd521 100644
--- a/date.c
+++ b/date.c
@@ -653,8 +653,12 @@ int parse_date_basic(const char *date, unsigned long *timestamp, int *offset)
if (*timestamp == -1)
return -1;
- if (!tm_gmt)
+ if (!tm_gmt) {
+ if ((time_t)*timestamp < (time_t)*offset * 60)
+ die("unsupported time before Epoch");
*timestamp -= *offset * 60;
+ }
+
return 0; /* success */
}
@@ -722,6 +726,8 @@ static unsigned long update_tm(struct tm *tm, struct tm *now, unsigned long sec)
n = mktime(tm) - sec;
localtime_r(&n, tm);
+ if (n < 0)
+ die("unsupported time before Epoch");
return n;
}
--
1.7.4.74.g639db
-- 8< --
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html