[tz] Some inconsistency in times during the transitions between DST and non-DST times...
Alan Lehotsky
alehotsky at codegentllc.com
Thu Jan 9 16:07:02 UTC 2020
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20200109/6398120c/attachment-0001.html>
More information about the tz
mailing list