Skip to content

[musl] strptime() question

3 messages · Rich Felker, Alba Pompeo

#
On Thu, Feb 04, 2016 at 04:35:22PM -0200, Alba Pompeo wrote:
I'm cc'ing both lists now.
The tzset function doesn't really do much interesting; it just updates
some global state to match the current value of the TZ environment
variable, but most time.h functions do this already anyway. Anyway
this doesn't really answer the question of what R's strptime function
is doing to add timezone functionality onto the underlying system's
strptime. Is R changing the environment (this is highly unsafe in any
potentially-multithreaded process, BTW)? Is it using the globals set
by tzset to compute adjustments to the result?

Rich
1 day later
#
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.
On Thu, Feb 4, 2016 at 7:32 PM, Rich Felker <dalias at libc.org> wrote:
#
On Sat, Feb 06, 2016 at 10:35:28AM -0200, Alba Pompeo wrote:
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