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?