[PATCH 10/10] timegm: add portable implementation (Solaris support)
Blake Jones
blakej at foo.net
Sun Nov 4 20:50:59 PST 2012
> 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
More information about the notmuch
mailing list