> That is a valid point. Yet it doesn't change the fact that I'd prefer
> to use timegm() where available. Internally, glibc uses the same code
> to implement both timegm() and mktime(), and I'd hate it if the
> results were subtly different depending on whether the time zone was
> specified in the input or not.

That's fine with me.

> That said, I'm not opposed to using your simple timegm() alternative
> in the compat code if you think it's good enough to get you going on
> Solaris.

I think it is, assuming you don't plan to use tm_wday or tm_yday in your
parse-time-string code, and that you don't plan to depend on the side
effect of timegm() canonicalizing the passed-in "struct tm".

> As to solving the compat linking problem, I think the patch at the end
> of this message should fix it. Please try that with the regular
> notmuch approach to portability. The general idea is to keep
> parse-time-string as independent as possible from the rest of notmuch
> (possibly turning it into a dynamic library and a package of its own
> eventually), but I think including compat.h is an acceptable exception
> to make.

Yeah, this seems to work.  I'll update my patch set accordingly.

Blake