Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 6 Feb 2016 17:55:23 -0500
From: Rich Felker <dalias@...c.org>
To: Alba Pompeo <albapompeo@...il.com>
Cc: r-devel <r-devel@...roject.org>, musl@...ts.openwall.com
Subject: Re: Re: Fwd: [Rd] strptime() question

On Sat, Feb 06, 2016 at 10:35:28AM -0200, Alba Pompeo wrote:
> It is setting TZ and using tzset(). R is not multi-threaded so it is safe.
> 
> Simon figure out the important settings from the config.log and
> config.h files on a musl system:
> 
> /* #undef USE_INTERNAL_MKTIME */
> #define HAVE_TM_GMTOFF 1
> #define HAVE_TM_ZONE 1
> 
> Does this help anyone debug the issue? Simon just went on vacation.

R's src/main/datetime.c does A LOT of munging to the output of
strptime and I wouldn't be surprised if they're making nonportable
assumptions about it. Note that the underlying C strptime function has
nothing to do with timezones or time conversion; it's basically just a
time-tailored sscanf that reads integers and strings from the input
string and converts them into values in the fields of struct tm.

It also looks like R isn't even calling the system strptime but
instead using its own R_strptime. I think that supports my theory that
the problem is in the munging being done after the string is parsed.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.