On Thu, Mar 9, 2017 at 2:10 PM, John Vogel <jvogel4_AT_stny.rr.com> wrote:
> On Wed, 8 Mar 2017 09:47:15 -0800
> Michael Forney <mforney_AT_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.
Received on Thu Mar 09 2017 - 23:53:11 CET