man mktime on my machine reveals: > The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. The

man mktime on my machine reveals: > The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. The function ignores the values supplied by the caller in the tm_wday and tm_yday fields. The value specified in the tm_isdst field informs mktime() whether or not daylight saving time (DST) is in effect for the time supplied in the tm structure: a positive value means DST is in effect; zero means that DST is not in effect; and a negative value means that mktime() should (use timezone information and system databases to) attempt to determine whether DST is in effect at the specified time. So, not specified. POSIX is no clearer about which choice it will make [1]: > The mktime() function shall convert the broken-down time, expressed as local time, in the structure pointed to by timeptr, into a time since the Epoch value with the same encoding as that of the values returned by time(). The original values of the tm_wday and tm_yday components of the structure shall be ignored, and the original values of the other components shall not be restricted to the ranges described in <time.h>. > A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time. > Local timezone information shall be set as though mktime() called tzset(). > The relationship between the tm structure (defined in the <time.h> header) and the time in seconds since the Epoch is that the result shall be as specified in the expression given in the definition of seconds since the Epoch (see XBD Seconds Since the Epoch) corrected for timezone and any seasonal time adjustments, where the names other than tm_yday in the structure and in the expression correspond, and the tm_yday value used in the expression is the day of the year from 0 to 365 inclusive, calculated from the other tm structure members specified in <time.h> (excluding tm_wday). > Upon successful completion, the values of the tm_wday and tm_yday components of the structure shall be set appropriately, and the other components shall be set to represent the specified time since the Epoch, but with their values forced to the ranges indicated in the <time.h> entry; the final value of tm_mday shall not be set until tm_mon and tm_year are determined. ... but i think the final paragraph implies that the tm_isdst field in the input time should at least be set to indicate which choice was made! Java is explicit [2]: > In most cases, there is only one valid offset for a local date-time. In the case of an overlap, where clocks are set back, there are two valid offsets. This method uses the earlier offset typically corresponding to "summer". [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/m... [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/LocalDateTime.html#atZone(java.time.ZoneId) https://docs.oracle.com/en/java/javase/11/docs/api/java.base...