I’m supporting a “port” of the tz code where I’ve selectively embedded pieces of localtime.c into an application , so this may be something I’ve broken, but I’ve looked fairly carefully at my implementation. There seems to be a problem with the binary search to find the nearest transition times, when you are within the “fall-behind” transition. If I am in the Europe/London timezone and have a time like "2019-10-27 01:16:46” converting it to UTC is producing the same time (because it ends up finding the non-DST range. But ONE second earlier ends up thinking it’s within the DST range, so "2019-10-27 01:16:45” ends up reporting “2019-10-2 00:16:45” I tried to use the gnu date command to see if I could reproduce this in a clean tz environment using the -u -d flags, and couldn’t duplicate the problems I’m seeing, so there’s a possibility that this is something I’m doing wrong. But the following experimental change in localsub makes it consistently pick the non-dst representation of the time. } else { int lo = 1; int hi = sp->timecnt; while (lo < hi) { int mid = (lo + hi) >> 1; if (t < sp->ats[mid]) hi = mid; else lo = mid + 1; } i = (int) sp->types[lo - 1]; // Check if this is a dst setting AND 't' is within the magic hour that // replays when we fall behind. In this case we always treat a time as // not in the dst. // if (sp->ttis[i].tt_isdst && (t - sp->ttis[i].tt_gmtoff) > sp->ats[lo-1]) i = (int) sp->types[lo]; } ttisp = &sp->ttis[i]; Does this make any sense?