Note that 2am doesn't exist on the local clock:  it leaps from 1:59:59 to 3:00:00.  You're claiming that one answer is "correct", but why?  The relevant _standards_ don't appear to specify what happens when the input is senseless.  Note that the behavior isn't really due to Python, but to the platform C libraries.

Windows is treating 2am as if DST were already in effect, so senseless times of the form 2:MM:SS are treated the same as 1:MM:SS before DST came into play.  Linux is treating 2am as if the DST switch hadn't yet happened, so senseless times of the form 2:MM:SS are treated the same as 3:MM:SS after DST came into play.

In favor of the Windows approach, since the last second when DST wasn't in effect was 01:59:59, it "makes sense" to treat the senseless 02:00:00 as if the DST switch happened.  In favor of the Linux approach, since 2am in fact doesn't exist on the local clock, it "makes sense" to imagine that the user simply forgot to set the clock forward, so 02:00:00 should be treated as not being in DST.  Neither is compelling.

If you care a lot ;-), on any platform you can _force_ the choice by forcing tm_isdst to a non-negative value.  For example, here on Windows:

    import time
    base = [2014, 3, 9, 2, 0, 0, 0, 0, None]
    for isdst in -1, 0, 1:
        base[-1] = isdst
        print("%2d" % isdst, time.mktime(time.struct_time(base)))

That prints:

-1 1394348400.0
 0 1394352000.0
 1 1394348400.0

Which confirms that Windows is treating the senseless time as if DST were already in effect - but can be forced to treat it as if DST weren't in effect by setting tm_isdst to 0.