uzimac at da3m0n8t3r.com
Tue Apr 16 22:39:02 PDT 2013
I'm totally new to DragonFlyBSD. I'm running:
DragonFly dragonfly.burplex.com 3.5-DEVELOPMENT DragonFly
v220.127.116.11.ge1320-DEVELOPMENT #1: Tue Apr 16 11:48:33 PDT 2013
root at dragonfly.burplex.com:/usr/obj/usr/src/sys/AISHA x86_64
w/ hammer filesystem, and it seems great so far.
I am curious about strptime() and mktime().
If I run this code on DragonFlyBSD
struct tm etm;
memset(&etm, 0, sizeof(struct tm));
strptime("Tue, 12 Feb 2013 23:02:45 +0100",
"%a, %d %b %Y %H:%M:%S %z",
epoch = mktime(&etm);
strftime(outstr, sizeof(outstr), "%a, %d %b %Y %T %z",
printf("%i %s", (int)epoch, outstr);
1360738965 Tue, 12 Feb 2013 23:02:45 -0800
which is incorrect, as you can see it's basically ignoring the offset "z".
This is because the strptime() function puts the parsed value of "z" into
GMTOFF in the tm struct, but mktime (which calls internal functions time1()
and time2()) totally ignores this field. The workaround is to pull out GMTOFF
from etm before calling mktime, then adding it back onto the returned epoch
Another BSD system's strptime() takes the parsed value from "z" and adds it to
tm_hour and tm_minute, does not set GMTOFF, so when you pass the structure to
mktime, etc, it returns the correct value.
1360706565 Tue, 12 Feb 2013 14:02:45 -0800
(Epoch is always expressed in seconds relative to GMT +0000 timezone.)
This 'feels' like a bug, however I have been told by respected authority this
behavior is POSIX standard, and the adjusted hour and minute code is
potentially not standard. I could argue that 'always' getting the wrong time
from a strptime/mktime combo isn't such a good thing. (?)
I'm curious about the experiences and feedback of other users, perhaps there
is something I'm missing with regards to strptime and mktime.
San Jose California USA
More information about the Users