time question

[Waitman Gobble <uzimac@xxxxxxxxxxxxxx>]

Hi,

I'm totally new to DragonFlyBSD. I'm running:

DragonFly dragonfly.burplex.com 3.5-DEVELOPMENT DragonFly
v3.5.0.50.ge1320-DEVELOPMENT #1: Tue Apr 16 11:48:33 PDT 2013    
root@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(). 

http://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/lib/libc/stdtime/strptime.c

http://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/lib/libc/stdtime/localtime.c


If I run this code on DragonFlyBSD

        struct tm       etm;
        time_t          epoch;
        char            outstr[200];

        memset(&etm, 0, sizeof(struct tm));

        strptime("Tue, 12 Feb 2013 23:02:45 +0100",
                        "%a, %d %b %Y %H:%M:%S %z",
                        &etm);

        epoch = mktime(&etm);

        strftime(outstr, sizeof(outstr), "%a, %d %b %Y %T %z",
                        localtime(&epoch));

        printf("%i %s", (int)epoch, outstr);

I get:

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
value.

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.

Thank you.

--
Waitman Gobble
San Jose California USA
+1.5108307875