On Thu, Mar 9, 2017 at 2:10 PM, John Vogel <jvog...@stny.rr.com> wrote: > On Wed, 8 Mar 2017 09:47:15 -0800 > Michael Forney <mfor...@mforney.org> wrote: > >> I pushed a slightly amended version of this patch to my sbase branch at >> https://github.com/michaelforney/sbase/commit/4b13b23a689da5fc01c2a26affe8ad8087c777bf. >> > > I am running into strange behavior in both this patch, as well as my last one. > I am pretty sure I tested it before, but I am not convinced I did so > thoroughly. > When setting the date, sometimes the result is as expected, sometimes the > result is wildly off. I have run it through gdb. The broke down time seems to > be set as expected. When inspecting struct tm date in either my patch or this > one, I notice garbage values in parts of the tm struct that are not being > set. I have tried two methods for addressing: (1) zeroing the date variable > with > memset and (2) declaring struct tm date as static. Both methods do the trick > and setting the date is consistent with input. I also considered explicitly > zeroing the members that are not touched, but since not all of them seem to be > required by posix, I thought that zeroing the whole struct made more sense.
I think it is safe to just set tm_sec to 0, and tm_isdst to -1 (so that mktime will attempt to guess whether or not DST is in effect). POSIX says that tm_wday and tm_yday are ignored, and the glibc manual (and musl implementation) says that the non-standard fields tm_gmtoff and tm_zone are also ignored.