Re: [Monotone-devel] Re: cvs_import and timezones

[Zack Weinberg]

On 10/17/06, Tony Tung <address@hidden> wrote:
> On Oct 17, 2006, at 2:42 PM, Zack Weinberg wrote:
> > Whether the manpage says it or not, I can pretty much guarantee you
> > libc does do this automatically on OSX and FreeBSD.  If it didn't, the
> > majority of programs that used localtime() would not work properly.
>
> Still, I see behavioral differences if I throw that into monotone's
> cvs_import(..) function.  No idea why.

The relevant chunk of code is in rcs_import.cc,
cvs_commit::cvs_commit() which does

 struct tm t;
 // We need to initialize t to all zeros, because strptime has a habit of
 // leaving bits of the data structure alone, letting garbage sneak into
 // our output.
 memset(&t, 0, sizeof(t));
 char const * dp = delta->second->date.c_str();
 L(FL("Calculating time of %s") % dp);
#ifdef HAVE_STRPTIME
 if (strptime(dp, "%y.%m.%d.%H.%M.%S", &t) == NULL)
   I(strptime(dp, "%Y.%m.%d.%H.%M.%S", &t) != NULL);
#else
 I(sscanf(dp, "%d.%d.%d.%d.%d.%d", &(t.tm_year), &(t.tm_mon),
          &(t.tm_mday), &(t.tm_hour), &(t.tm_min), &(t.tm_sec))==6);
 t.tm_mon--;
 // Apparently some RCS files have 2 digit years, others four; tm always
 // wants a 2 (or 3) digit year (years since 1900).
 if (t.tm_year > 1900)
   t.tm_year-=1900;
#endif
 time = mktime(&t);

[Tangential observation: I don't see that conditional use of
strptime() here is actually buying us anything, and may actually be
wrong -- we'd have to do some investigation to find out exactly what
historical (pre-four-digit-year) versions of RCS/CVS did with dates in
the 00..69 range (rcsfile(5) claims that they're 1900..1969, which is
*not* what %y does on modern systems, but I strongly suspect that %y's
behavior is more correct "in real life") -- anyway, whatever RCS/CVS
actually does, it would be better to parse the year by hand and
hardwire a heuristic that we know matches that.  Anyway, none of this
has anything to do with time zones.]

The function responsible for handling time zones here is mktime().  My
knee-jerk reaction is that mktime() is buggy on your system, but there
is additional hair involved related to the handling of the (not always
present - it's a BSD extension, that for some damn reason failed to
get picked up by POSIX.2001) tm_gmtoff and tm_zone fields.  The Linux
manpage for mktime(3) does not document these fields in sufficient
detail and I don't have anything else to hand.  (What system are you
using?)  So here's another test program... if it fails to compile on
your system, add -DNO_GMTOFF to the compiler command line, and just
run it once with no arguments; if it compiles fine as is, run it four
times with the arguments 0, 1, 2, and 3, and I'm very interested in
any differences.  [For reference, on Linux/glibc2 this prints
"1143867600" twice no matter what argument.  Which I would argue is
*wrong*, but... here we go tangenting again.  Sigh.]

zw