From: David Woodhouse Date: Sun, 24 Apr 2005 06:38:49 GMT Subject: Re: Date handling. Message-ID: <1114324729.3419.78.camel@localhost.localdomain> In-Reply-To: <20050424030416.GE16751@delft.aura.cs.cmu.edu> On Sat, 2005-04-23 at 23:04 -0400, Jan Harkes wrote: > I noticed that some commit timestamps seemed to be off, looking into it > a bit more it seems like mktime is influenced by the setting of the > local TZ environment. Ewww. I missed that in the documentation. I suppose I should have worked it out having empirically determined that it ignores the tm_gmtoff field. > The question is, do we want to just calculate the time_t offset > ourselves without using mktime, or force the TZ environment to UTC. I don't think we want to be in the business of counting leap seconds; we need to let the system do it. I don't much like setting TZ to UTC though -- how about we use your test case to find the offset and subtract that? Does this work? Index: commit-tree.c =================================================================== --- 31e9af73983d640090508b06784ef7db4816c957/commit-tree.c (mode:100644 sha1:c0b07f89286c3f6cceae8122b4c3142c8efaf8e1) +++ uncommitted/commit-tree.c (mode:100664) @@ -138,10 +138,14 @@ struct tm tm; char *p; int i, offset; - time_t then; + time_t then, localofs; memset(&tm, 0, sizeof(tm)); + tm.tm_mday = 1; + tm.tm_year = 70; + localofs = mktime(&tm); + /* Skip day-name */ p = skipfws(date); if (!isdigit(*p)) { @@ -246,7 +250,9 @@ if (*(skipfws(p + 5))) return; - then = mktime(&tm); /* mktime appears to ignore the GMT offset, stupidly */ + /* No way to convert to a time_t and honour tm_gmtoff; we have to + do the evil trick by subtracting the local offset */ + then = mktime(&tm) - localofs; if (then == -1) return; -- dwmw2