Do you realize that a typical portable implementation of mktime calls localtime up to four times to get tm_isdst? And to get it completely "right", needs up to six calls?  I am sure I can do no worse than that computing the fold value.
Related: last night I was "amused" to see this in Gustavo's dateutil's tz.py's tzlocal implementation:
def _isdst(self, dt): # We can't use mktime here. It is unstable when deciding if # the hour near to a change is DST or not.
followed by examples from his native Brazilian timezone, then his own code to try to get it right. mktime is a frickin' cross-platform mess, and anyone determined to get transitions exactly right in all cases on all platforms should be scared to death of using it.
Stewart, I still don't grasp what your problem is. The only concrete example I've seen is dealing with this string:
2004-10-31 01:15 EST-05:00
where you knew "EST" meant US/Eastern, but you haven't explained exactly what you're trying to _do_ with it. If you're trying to create an aware datetime out of it in a post-PEP-495 pytz, then "the obvious" way is:
1. Create a UTC datetime out of "2004-10-31 01:15" alone. 2. Create timedelta(hours=-5) out of "-05:00" alone. 3. Subtract the result of #2 from the result of #1, to convert to UTC for real. 4. Invoke .astimezone() on the result of #3, passing pytz's spelling of "US/Eastern".
You (the user doing this) don't have to compute - or even know anything about - "fold" yourself. pytz's .fromutc() is the only part that has to know about "fold". The whole dance doesn't require invoking _any_ dodgy platform C library date functions. Absolutely everything known about transitions in this dance comes from pytz's wrapping of zoneinfo, so you're (Stuart) entirely in control of what happens, and all pytz users will get exactly the same result on all platforms. And none of it "should be" notably expensive.
If that doesn't answer it, what - exactly - _are_ you trying to do with that string?