Since it would be very confusing to have something called isdst that does not have the same semantics as tm_isdst , we need a different name. Moreover, the datetime.datetime class already has a method called dst() and if we called fold "isdst", we would necessarily have situations when "isdst" is zero but dst() is not or the other way around.

Unlike tm_isdst , the proposed fold attribute has no effect on the interpretation of the datetime instance unless without that attribute two (or no) interpretations are possible.

If the programmer misspecified a non-negative value of tm_isdst to time.mktime , the result will be time that is 1 hour off and since there is rarely a way to know anything about DST before a call to time.mktime is made, the only sane choice is usually tm_isdst=-1 .

The main problem with the tm_isdst field is that it is impossible to know what value is appropriate for tm_isdst without knowing the details about the time zone that are only available to the tzinfo implementation. Thus while tm_isdst is useful in the output of methods such as time.localtime , it is cumbersome as an input of methods such as time.mktime .

While the tm_isdst field of the time.struct_time object can be used to disambiguate local times in the fold, the semantics of such disambiguation are completely different from the proposal in this PEP.

Suggested by Guido van Rossum and favored by one (but initially disfavored by another) author. A consensus was reached after the allowed values for the attribute were changed from False/True to 0/1. The noun "fold" has correct connotations and easy mnemonic rules, but at the same time does not invite unbased assumptions.

This was a working name of the attribute chosen initially because the obvious alternative ("second") conflicts with the existing attribute. It was rejected mostly on the grounds that it would make True a default value.

Several reasons have been raised to allow a None or -1 value for the fold attribute: backward compatibility, analogy with tm_isdst and strict checking for invalid times.

Backward Compatibility It has been suggested that backward compatibility can be improved if the default value of the fold flag was None which would signal that pre-PEP behavior is requested. Based on the analysis below, we believe that the proposed changes with the fold=0 default are sufficiently backward compatible. This PEP provides only three ways for a program to discover that two otherwise identical datetime instances have different values of fold : (1) an explicit check of the fold attribute; (2) if the instances are naive - conversion to another timezone using the astimezone() method; and (3) conversion to float using the timestamp() method. Since fold is a new attribute, the first option is not available to the existing programs. Note that option (2) only works for naive datetimes that happen to be in a fold or a gap in the system time zone. In all other cases, the value of fold will be ignored in the conversion unless the instances use a fold -aware tzinfo which would not be available in a pre-PEP program. Similarly, the astimezone() called on a naive instance will not be available in such program because astimezone() does not currently work with naive datetimes. This leaves us with only one situation where an existing program can start producing different results after the implementation of this PEP: when a datetime.timestamp() method is called on a naive datetime instance that happen to be in the fold or the gap. In the current implementation, the result is undefined. Depending on the system mktime implementation, the programs can see different results or errors in those cases. With this PEP in place, the value of timestamp will be well-defined in those cases but will depend on the value of the fold flag. We consider the change in datetime.timestamp() method behavior a bug fix enabled by this PEP. The old behavior can still be emulated by the users who depend on it by writing time.mktime(dt.timetuple()) + 1e-6*dt.microsecond instead of dt.timestamp() .

Analogy with tm_isdst The time.mktime interface allows three values for the tm_isdst flag: -1, 0, and 1. As we explained above, -1 (asking mktime to determine whether DST is in effect for the given time from the rest of the fields) is the only choice that is useful in practice. With the fold flag, however, datetime.timestamp() will return the same value as mktime with tm_isdst=-1 in 99.98% of the time for most time zones with DST transitions. Moreover, tm_isdst=-1 -like behavior is specified regardless of the value of fold . It is only in the 0.02% cases (2 hours per year) that the datetime.timestamp() and mktime with tm_isdst=-1 may disagree. However, even in this case, most of the mktime implementations will return the fold=0 or the fold=1 value even though relevant standards allow mktime to return -1 and set an error code in those cases. In other words, tm_isdst=-1 behavior is not missing from this PEP. To the contrary, it is the only behavior provided in two different well-defined flavors. The behavior that is missing is when a given local hour is interpreted as a different local hour because of the misspecified tm_isdst . For example, in the DST-observing time zones in the Northern hemisphere (where DST is in effect in June) one can get >>> from time import mktime, localtime >>> t = mktime((2015, 6, 1, 12, 0, 0, -1, -1, 0)) >>> localtime(t)[:] (2015, 6, 1, 13, 0, 0, 0, 152, 1) Note that 12:00 was interpreted as 13:00 by mktime . With the datetime.timestamp , datetime.fromtimestamp , it is currently guaranteed that >>> t = datetime.datetime(2015, 6, 1, 12).timestamp() >>> datetime.datetime.fromtimestamp(t) datetime.datetime(2015, 6, 1, 12, 0) This PEP extends the same guarantee to both values of fold : >>> t = datetime.datetime(2015, 6, 1, 12, fold=0).timestamp() >>> datetime.datetime.fromtimestamp(t) datetime.datetime(2015, 6, 1, 12, 0) >>> t = datetime.datetime(2015, 6, 1, 12, fold=1).timestamp() >>> datetime.datetime.fromtimestamp(t) datetime.datetime(2015, 6, 1, 12, 0) Thus one of the suggested uses for fold=-1 -- to match the legacy behavior -- is not needed. Either choice of fold will match the old behavior except in the few cases where the old behavior was undefined.